-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JIT: small OSR locals must be normalize on load #84000
Conversation
When I changed the importation strategy for OSR in dotnet#83910 it exposed a latent issue -- small OSR locals must normalized on load. Fixes dotnet#83959.
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak |
@jakobbotsch PTAL |
Expecting a modest number of diffs for OSR methods. |
/azp run runtime-coreclr libraries-pgo |
Azure Pipelines successfully started running 1 pipeline(s). |
May also fix #83960 -- checking that now. |
/azp run runtime-coreclr pgostress |
Azure Pipelines successfully started running 1 pipeline(s). |
Running into various issues:
|
Seems like it does, but locally I am hitting another odd error. Running on a Coffee Lake i7 8700 so no AVX-512, I end up here when running under WSL2 when built against ed3721b.
|
Found the issue: #84012 |
src/coreclr/jit/compiler.h
Outdated
(lvIsParam || m_addrExposed || lvIsStructField || lvIsOSRLocal); | ||
} | ||
|
||
bool lvNormalizeOnStore() const | ||
{ | ||
return varTypeIsSmall(TypeGet()) && | ||
// lvIsStructField is treated the same as the aliased local, see fgDoNormalizeOnStore. | ||
!(lvIsParam || m_addrExposed || lvIsStructField); | ||
!(lvIsParam || m_addrExposed || lvIsStructField || lvIsOSRLocal); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took me a while to guess that the reason is that the local could have been marked normalize-on-load in tier-0 due to the more conservative address exposure there. Maybe add a comment to that effect?
Also, I guess if we wanted to we could scope this down to just OSR locals that were address exposed in tier 0, since we have that information available.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about scoping it down, so let me do that (will need a new bit on lclvar dsc).
/azp run runtime-coreclr libraries-pgo, runtime-coreclr pgostress |
Azure Pipelines successfully started running 2 pipeline(s). |
So far just this one failure has recurred:
Does not repro locally, suspect it requires AVX-512. @tannergooding how can I repro this w/o having AVX-512 capable hardware? |
Also seeing an arm64 failure. Not sure it is related but will take a look.
|
Bruce pointed out a mismatched VM altjit would work -- I tried this via windows crossjit on linux -- and while I do indeed see zmm's in the disasm, I can't yet repro the assertion failure.
|
There aren't any OSR methods in this test, so the failure seems unrelated. |
Going to merge since we have potential OSR silent bad code; will try and repro the AVX512 issue some other way. |
When I changed the importation strategy for OSR in #83910 it exposed a latent issue -- small OSR locals must normalized on load if they were exposed at Tier0.
Fixes #83959.