@EgorBo PTAL
cc @dotnet/jit-contrib

Surprising (though small) number of diffs though many of those look like bool cases where the bits we don't compare happen to be zero, so we were getting lucky.

This only affects local AP an only in the (relatively new) cross-block mode introduced in #94741.

This was reported as a .NET 9 issue so I will propose a backport.

Surprising (though small) number of diffs though many of those look like bool cases where the bits we don't compare happen to be zero, so we were getting lucky.

Can you share some of those cases? I think it should be ok to scope the check here to TYP_INT uses of TYP_LONG LclVarDsc. The small cases come with normalization guarantees.

here is one of the simpler ones

29948.base.txt
29948.diff.txt

The base there looks ok to me. V04 is normalize-on-store, so its upper 24 bits are always going to be zero

So you think just the TYP_LONG locals are at risk?

Seems plausible because this sort of pattern must be rare or we'd have found this long ago.

So you think just the TYP_LONG locals are at risk?

I think so, yes. We allow accessing lower 32 bits of TYP_LONG locals with TYP_INT GenTreeLclVar, but the same thing is not allowed for smaller types (a small typed GenTreeLclVar really does mean a 32 bit int with some form of normalization in the upper bits).
There was a somewhat recent discussion about getting rid of this former case with the Samsung folks, at least until lowering... Seems like here we have some more motivation. optNarrowTree is one of the places that creates it today.

Ok, did that. Now no diffs locally.

/backport to release/9.0

Started backporting to release/9.0: https://github.com/dotnet/runtime/actions/runs/13317332242

/backport to release/9.0-staging

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/13318074756