Set lvSingleDef for non TYP_REF locals

[MichalPetryka]

Sets lvSingleDef for non TYP_REF locals, currently this should only affect reuse of RET_EXPR spills.

Split off from #85197.

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Sets lvSingleDef for non TYP_REF locals, currently this should only affect reuse of RET_EXPR spills.

Split off from #85197.

Author:	MichalPetryka
Assignees:	-
Labels:	area-CodeGen-coreclr, community-contribution
Milestone:	-

[MichalPetryka]

Diffs are mostly moves being shuffled around and more places being affected by #85547.

[AndyAyersMS]

Can you write up a summary of the diffs this causes? Make sure to include some of the ASP.NET regressions, eg:

Top method regressions (percentages):
27 (18.88 % of base) : 24443.dasm - System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1+StateMachineBox`1[int,Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestStream+<ReadAsyncInternal>d__30]:RentFromCache():System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1+StateMachineBox`1[int,Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestStream+<ReadAsyncInternal>d__30]

[MichalPetryka]

Can you write up a summary of the diffs this causes? Make sure to include some of the ASP.NET regressions, eg:

That specific one is caused by PGO marking a block as zero weight which blocks CSE, as per @SingleAccretion handling that would be tricky.
A fair bit of diffs are due to cmov conversion failing as per the mentioned issue.
And most diffs are due to the JIT using less variables so it emits less assigns from one var to another, leading to cascading diffs.

[jakobbotsch]

A fair bit of diffs are due to cmov conversion failing as per the mentioned issue.

That issue is just the reason why it looks less efficient than it could be, but what is the reason that jump threading kicks in now but not before?

[MichalPetryka]

but what is the reason that jump threading kicks in now but not before?

It's because inlinees now assign their returns directly to the variable in the method they're inlined to, instead of to a temp that's later assigned to the variable which I assume happend to block it.

[AndyAyersMS]

but what is the reason that jump threading kicks in now but not before?

It's because inlinees now assign their returns directly to the variable in the method they're inlined to, instead of to a temp that's later assigned to the variable which I assume happend to block it.

Jump threading can't handle cases where the block to thread has side effects, so it could be by reusing a temp we're avoiding a temp to temp copy in an unfortunate spot.

[AndyAyersMS]

Looks good to me now. Thanks!