Skip to content
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 known generic casts not elided #38106

Closed
HurricanKai opened this issue Jun 18, 2020 · 3 comments · Fixed by #38163
Closed

JIT known generic casts not elided #38106

HurricanKai opened this issue Jun 18, 2020 · 3 comments · Fixed by #38163
Assignees
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Milestone

Comments

@HurricanKai
Copy link
Member

Description

When writing generic types, using a pattern as seen in Vector<T> (if (typeof(T) == typeof(int)) ... if (typeof(T) == typeof(float)) ...) once this construct grows to 9 blocks JIT will end up not correctly eliding some casts:
See sharplab
Removing any two blocks from As2<T> will improve code gen significantly (matching a non-generic version & the other version)
splitting up the function will also resolve the issue.

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI untriaged New issue has not been triaged by the area owner labels Jun 18, 2020
@AndyAyersMS
Copy link
Member

The sharplab link is showing codegen for . Net Framework x86 jit. For core this sharplab is more relevant.

Either way we're tail calling into C.As2 instead of inlining it, which seems odd. I'll dig in and see what's up.

C.AsByte2(Single)
    L0000: vzeroupper
    L0003: mov rax, C.As2[[System.Byte, System.Private.CoreLib]](Single)
    L000d: jmp rax

@SingleAccretion
Copy link
Contributor

SingleAccretion commented Jun 18, 2020

@AndyAyersMS This is a bit of common pattern that I've noticed while using Sharplab, primarily because it comes up when doing this. I've always assumed it was some bug "in the toolchain".

@AndyAyersMS AndyAyersMS removed the untriaged New issue has not been triaged by the area owner label Jun 18, 2020
@AndyAyersMS AndyAyersMS added this to the 5.0.0 milestone Jun 18, 2020
@AndyAyersMS
Copy link
Member

The inliner has a budget that it uses to prevent runaway inlining, and it is tripping (prematurely) in this case, as (generally speaking) AggressiveInlining methods should be exempt from budgeting.

Inlines into 06000003 C:AsByte2(float):ubyte
  [0 IL=0001 TR=000001 06000006] [FAILED: inline exceeds budget] C:As2(float):ubyte

That explains why the behavior changes as more checks are added -- at some point the extra IL pushes As2 over budget.

Let me look into fixing this.

AndyAyersMS added a commit to AndyAyersMS/runtime that referenced this issue Jun 19, 2020
If we have a very small root method that calls a large method that is marked with
AggressiveInlining, we may fail to inline because of a budget check.

Allow such inlines to bypass the check.

Closes dotnet#38106.
@AndyAyersMS AndyAyersMS self-assigned this Jun 23, 2020
AndyAyersMS added a commit that referenced this issue Jun 23, 2020
If we have a very small root method that calls a large method that is marked with
AggressiveInlining, we may fail to inline because of a budget check.

Allow such inlines to bypass the check.

Closes #38106.
@ghost ghost locked as resolved and limited conversation to collaborators Dec 8, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants