-
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
Fix GetHardwareIntrinsicId
on 32bit platforms
#110238
Conversation
AFAIK methods on the nested X64/Arm64 classes shouldn't be considered intrinsics on 32bit platforms since they are as relevant as e.g. WASM intrinsics. This should fix widespread runtime-nativeaot-outerloop failure on x86. I think this regressed in dotnet#109137.
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas |
/azp run runtime-nativeaot-outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
There was a slight change to the ISA mapping logic in #109137, but I don't believe it could have caused any change in behavior. runtime/src/coreclr/tools/Common/JitInterface/CorInfoInstructionSet.cs Lines 1420 to 1517 in d6eb354
Previously, a 64-bit nested class, e.g. The fixup for 64-bit platforms is there because the Anyway, I do see some failures from illegal instruction encoding for GFNI instructions, which landed a day or two after the mentioned PR and was also mine. I'll see what those are and put up a fix. |
Looks like the scenario that's failing is that |
And actually, now that I think about it, that's the correct behavior for NAOT. Since we add The easy fix is to remove The comments indicate that list is meant to be things that are highly likely to exist on most hardware, which GFNI currently is not. The interesting thing is, if we were to test on hardware that lacked support for any of the other opportunistic ISAs, we'd see exactly the same failures. runtime/src/coreclr/tools/Common/InstructionSetHelpers.cs Lines 185 to 196 in d6eb354
|
|
It looks like |
Ah, I see the bug now. Nested classes don't have a namespace, so the Seems we need both this one and #110250 The special handling for the 64-bit ISA variants is confusing, where they're hidden sometimes and explicit sometimes. If it's ok, I'd like to take a look at cleaning that up, along with all the other implied ISAs that are currently leaking into the |
Yes, your PR is likely to fix #110240 (I filed that one as a bug since I didn't know where the fix would be).
I would welcome anything that simplifies this since I don't understand any of this, but cc @tannergooding on that. |
/azp run runtime-nativeaot-outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
@tannergooding could you have a look when you get a chance? |
Also happy for things to be simplified here. I believe we have a tracking issue already discussing some of the leakage and ways we’d like to clean it up |
AFAIK methods on the nested X64/Arm64 classes shouldn't be considered intrinsics on 32bit platforms since they are as relevant as e.g. WASM intrinsics. This should fix widespread runtime-nativeaot-outerloop failure on x86. I think this regressed in dotnet#109137.
AFAIK methods on the nested X64/Arm64 classes shouldn't be considered intrinsics on 32bit platforms since they are as relevant as e.g. WASM intrinsics. This should fix widespread runtime-nativeaot-outerloop failure on x86. I think this regressed in dotnet#109137.
AFAIK methods on the nested X64/Arm64 classes shouldn't be considered intrinsics on 32bit platforms since they are as relevant as e.g. WASM intrinsics. This should fix widespread runtime-nativeaot-outerloop failure on x86. I think this regressed in #109137.
Cc @dotnet/ilc-contrib