-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Don't treat Math.Round, Math.Ceiling, or Math.Floor as intrinsics if we are pre-jitting. #25365
Conversation
The following are all the places where we currently use
I'm still going through these, but it looks like there may be a couple other places that need to be fixed up as well (this is ignoring any code path that uses the VEX encoding, as those are currently forced to |
Went through the entries and updated a couple more places. Namely, the SIMD intrinsics use a "support level" to determine how they should be generated (this impacts |
src/jit/compiler.h
Outdated
@@ -7466,6 +7466,11 @@ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | |||
#pragma endregion // Note: region is NOT under !defined(__GNUC__) | |||
#endif | |||
|
|||
bool IsPreJIT() | |||
{ | |||
return jitFlags->IsSet(JitFlags::JIT_FLAG_PREJIT); |
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.
There are a lot of places in the JIT that just do jitFlags->IsSet(JitFlags::JIT_FLAG_PREJIT);
directly, it might be useful to update those to call IsPreJIT()
post the 3.0 snap.
src/jit/compiler.h
Outdated
@@ -8297,6 +8277,11 @@ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | |||
} | |||
#endif | |||
|
|||
bool IsPreJIT() |
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.
Why do you need to check whether this is PreJIT?
This should be based solely on the available instruction set, no?
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.
Ok, I see.
Would it be better to filter out the problematic methods in FilterHardwareIntrinsicMethodAttribs
instead. I think it would be nice to have the hacks required to make the intrinsics in CoreLib work in a central place.
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 went with this as I believed it to be the minimal set of changes needed for netcoreapp3.0 and would have the least impact on what code could be AOT'd.
If we are just talking about S.P.Corelib, I think we would only need to filter out the Math.Round
, Math.Ceiling
, and Math.Floor
methods (as the other relevant changes apply to the Vector64/128/256<T>
helper methods, which should already be getting filtered).
If we go a bit broader, this also impacts various codegen around FEATURE_SIMD
with relation to the "SIMD support level" which can be AVX2
, SSE41
, or SSE2
. At first glance, that mostly looks limited to the SIMD intrinsics (and therefore, outside of Vector<T>
, to the System.Numerics
library), but there is quite a bit of handling around those and I didn't go through it all.
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.
If we did filter them in FilterHardwareIntrinsicMethodAttribs
, that might also limit the AOT codegen quality if/when we expand the support beyond S.P.Corelib (but that could also be handled at that point in time.)
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.
The strategy to expand to support outside CoreLib will need to be different. So I think it would be best to keep the hack required to make the CoreLib work centralized, and not spread it around.
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.
Hmmm, Math.Ceiling
and Math.Floor
might be problematic. They are still FCALLs and so only get CORINFO_FLG_INTRINSIC
. Math.Round
, however, is a named intrinsic and so can go through the normal filtering.
Do we have a good way of allowing Math.Ceiling
/Math.Floor
to still be resolved to their CRT helper but not allowing the additional intrinsic handling?
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.
In ZapInfo::getIntrinsicID
, check the CORINFO_INTRINSIC_Ceiling
/ CORINFO_INTRINSIC_Floor
and return CORINFO_INTRINSIC_Illegal
instead.
Overall this seems reasonable. Just to clarify/verify a couple of things:
|
Thanks for looking into this and sorry for the trouble! I like Jan's suggestion of filtering this in the zapper because it makes this more centralized - if we later add command line switches that people have been asking for ("assume the target ISA is XYZ and generate the best code for that"), we'll only have to pipe that switch within the zapper - RyuJIT won't have to learn about those kinds of |
I believe @jkotas would prefer all of the checks to be routed through the zapper. Having gone through the code that uses I believe the |
…endent on the ISAs supported by the target CPU.
Updated to be done exclusively in the zapper. That resulted in me renaming |
This does not touch |
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.
Thanks
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 thanks! - it definitely seems cleaner to handle this in the zapper.
@MichalStrehovsky, could you give this a look as well? |
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.
Thanks for cleaning up the Filter
method!
Has to be scoped out for now because of the reasons in dotnet/coreclr#25365. Can't apply the same strategy as in that pull request because we precompile `Vector<T>` here (we always JIT in CoreCLR).
…endent on the ISAs supported by the target CPU. (dotnet/coreclr#25365) Commit migrated from dotnet/coreclr@133e857
This resolves https://github.com/dotnet/corefx/issues/38762