-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Do not fold mismatched OBJ(ADDR(LCL_VAR))
#69271
Do not fold mismatched OBJ(ADDR(LCL_VAR))
#69271
Conversation
The transforms in question could fold, e. g. "OBJ<8>(ADDR(LCL_VAR<16>))" to just the "LCL_VAR", necessitating workarounds in block morphing that had to rematerialize the block node to restore IR's validity. It is better to simply not create questionable IR in the first place.
@SingleAccretion is this ready? |
Unfortunately not yet, the updated SPMI collections have uncovered a couple regressions that have to be solved. |
92fcb08
to
d6d9966
Compare
By using layout compatibility in "gtNewStructVal" instead of handle equality. This is safe to do because "gtNewStructVal" is only used in contexts of block copies (as opposed to call arguments).
d6d9966
to
565ef7f
Compare
The diffs look more reasonable with the fix: SPMI in CI. There are still regressions, caused by the fix itself, where we forward-substitute a multi-reg call and the new local defined by it is marked as multi-reg, excluding it from SSA-based optimizations. I think the low number of said regressions (and the fact there are some improvements too) makes the change overall acceptable. @dotnet/jit-contrib |
// The normalized type to use in IR for block nodes with this layout. | ||
const var_types m_type; |
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.
This increases the size of ClassLayout
by one pointer. I measured the overall impact on memory consumption when CG-ing x64 CoreLib, it looked insignificant:
./diff-mem x64
Relative difference is: 0.007%
(This is a memory-CPU tradeoff: impNormStructType
is not a cheap function)
The transforms in question could fold, e. g.,
OBJ<8>(ADDR(LCL_VAR<16>))
to just theLCL_VAR
, necessitating workarounds in block morphing that had to rematerialize the block node to restore IR's validity.It is better to simply not create questionable IR in the first place.
We're expecting a small number of diffs due to using
OBJ
s instead ofIND
s in more cases.Fixes #69232.
What was the problem in #69232?
It was a problem introduced by #68712 and exposed with #68739.
Minimal reproduction:
Importation, through the magic of skipping
ADDR
s ingtNewCpObjNode
andgtNewBlkOpNode
created the following type-mismatched tree:This on its own should be "fine" since block morphing is supposed to compensate for this mismatch, by wrapping the local in an
OBJ(ADDR)
here:runtime/src/coreclr/jit/morph.cpp
Lines 9833 to 9865 in e502177
However, it fails, because it creates an
OBJ
node ofTYP_SIMD16
(usingV01
's handle). Before #68712, it would have created a handle-lessIND
node and not run into this problem.I decided to fix the source of the problem instead of extending the workaround in morph because: a) it was simpler, b) I wanted to delete this questionable folding for quite some time as it was causing similar problems elsewhere.