-
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: Avoid mask<->vector optimization for masks used in unhandled ways #110307
Conversation
When a local is used as a return buffer it is not address exposed, so the address-exposure check was not sufficient. Add checks for `LCL_ADDR`, `LCL_FLD` and `STORE_LCL_FLD` to make sure any use of a mask local that is not converted disqualifies it from participating in the optimization.
15b3c39
to
a8a0d8d
Compare
I haven't looked into them, but I suspect this will also fix the "Assert |
cc @dotnet/jit-contrib PTAL @a74nh @tannergooding |
Do we not have an outerloop job testing Is that why these didn't get caught after the initial PR went in, and only after the x64 support came online? |
The existing pipeline is broken because it was not testing the right thing. I had #107475 but I saw some other non-sve failures which I didn't get time to investigate. We would get Cobalt machines in CI added shortly, so going forward, it will get caught naturally. |
This doesn't repro on arm64 because SIMD16 is always returned by value there, which the existing checks handled. On xarch we have the possibility of the vector being defined as a return buffer, where it doesn't end up address exposed. The checks weren't sufficient for that. |
Could this appear on Arm64? Interesting as I never saw any failures myself on Fuzzlyn Arm64. |
I don't believe we do this for cases like |
16 byte structs on ARM64 are returned in two registers, not via return buffer. |
The |
For some classifications, not all classifications. There are multiple factors that influence it including total size, whether it is all integer, all floating-point, all SIMD, or mixed data types, etc. The classifications are effectively But regardless, my point was that I imagine this general issue should've been reproducible on SVE, it is not unique to x64 |
If we had larger SIMD types on arm64 than TYP_SIMD16, then yes, it would presumably be reproducible. But as it currently is, since we only end up with |
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.
LGTM
/azp run Antigen |
Azure Pipelines successfully started running 1 pipeline(s). |
/ba-g Helix work item was dead-lettered |
dotnet#110307) When a local is used as a return buffer it is not address exposed, so the address-exposure check was not sufficient. Add checks for `LCL_ADDR`, `LCL_FLD` and `STORE_LCL_FLD` to make sure any use of a mask local that is not converted disqualifies it from participating in the optimization. Also avoid doing some work for locals that are not SIMD/mask typed (common case). Previously we would do some unnecessary hash table lookups and other things in these cases.
dotnet#110307) When a local is used as a return buffer it is not address exposed, so the address-exposure check was not sufficient. Add checks for `LCL_ADDR`, `LCL_FLD` and `STORE_LCL_FLD` to make sure any use of a mask local that is not converted disqualifies it from participating in the optimization. Also avoid doing some work for locals that are not SIMD/mask typed (common case). Previously we would do some unnecessary hash table lookups and other things in these cases.
When a local is used as a return buffer it is not address exposed, so the address-exposure check was not sufficient. Add checks for
LCL_ADDR
,LCL_FLD
andSTORE_LCL_FLD
to make sure any use of a mask local that is not converted disqualifies it from participating in the optimization.Also avoid doing some work for locals that are not SIMD/mask typed (common case). Previously we would do some unnecessary hash table lookups and other things in these cases.
Fix #110306