runtime: Vector128/256: Too many calls to "ThrowIfUnsupportedType" prevents inlining
I am trying to optimize certain generic helpers of Vector128/256<T> by HW intrinsic and other helpers, which relies on inlining to get the optimal codegen. However, sometimes these helpers cannot get inlined due to “inline exceeds budget” because too many ThrowIfUnsupportedType need to be eliminated by inlining. This issue may give users unexpected codegen when they heavily use generic Vector128/256<T> helpers (e.g., Count, GetLower, etc.)
https://github.com/dotnet/coreclr/blob/10c3e60c863d01f638daa240af957c3c5791cda5/src/System.Private.CoreLib/shared/System/Runtime/Intrinsics/Vector256_1.cs#L342-L347
https://github.com/dotnet/coreclr/blob/10c3e60c863d01f638daa240af957c3c5791cda5/src/System.Private.CoreLib/shared/System/Runtime/Intrinsics/Vector256_1.cs#L78-L103
We need to find an approach to reduce the number of ThrowIfUnsupportedType call-site.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 24 (24 by maintainers)
Commits related to this issue
- JIT: modify inline budget update to use estimated imported IL size The inliner keeps a time budget to try and avoid pathological runaway inline behavior (see #4375). The jit estimates the time impact... — committed to AndyAyersMS/coreclr by AndyAyersMS 5 years ago
- JIT: modify inline budget update to use estimated imported IL size The inliner keeps a time budget to try and avoid pathological runaway inline behavior (see #4375). The jit estimates the time impact... — committed to AndyAyersMS/coreclr by AndyAyersMS 5 years ago
For those of you curious to know more about this aspect of the inliner, take a look at dotnet/coreclr#4375.