Mark promoted SIMD locals used by HWIs as DNER #64855
Conversation
ghost
added
the
community-contribution
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsAs the added comment states, we must do this to get dependent promotion, as otherwise the compiler does not support independent promotion of structs not fully eliminated from the IR, save some special cases (such as multi-reg structs). We will only need to do this very rarely, as otherwise we mark SIMD locals used by SIMDs/HWIs specially when creating those nodes so as not to promote them. This issue was revealed by forward substituion, where we had: SIMD a = OBJ(ADDR(b)) // b is SIMD too
HWI(a)And forward-substituted the promoted "b" into "HWI". Notably, by the time we are forward-substituting, "we cannot really do anything about it", as struct promotion has already run, and by the time we get to morph, we too cannot do much save some gymnastics with conjuring up a tree of inserts from individual fields. No diffs are expected. Side note: this is a conservative solution, but is always correct and does not put us in a worse position CQ-wise than before. It is possible/probable that we can "do better" at marking SIMD locals as "no promotion", or abandoning promotion for them altogether, but that is out of scope for this assert fix.
|
SingleAccretion
force-pushed
the
Force-Dep-Promotion-For-Simds
branch
from
5c3a78b
to
afde19d
Compare
As the added comment states, we must do this to get dependent promotion, as otherwise the compiler does not support independent promotion of structs not fully eliminated from the IR, save some special cases (such as multi-reg structs). We will only need to do this very rarely, as otherwise we mark SIMD locals used by SIMDs/HWIs specially when creating those nodes so as not to promote them. This issue was revealed by forward substituion, where we had: SIMD a = OBJ(ADDR(b)) // b is SIMD too HWI(a) And forward-substituted the promoted "b" into "HWI". Notably, by the time we are forward-substituting, "we cannot really do anything about it", as struct promotion has already run, and by the time we get to morph, we too cannot do much save some gymnastics with conjuring up a tree of inserts from individual fields.
SingleAccretion
force-pushed
the
Force-Dep-Promotion-For-Simds
branch
from
afde19d
to
8f7178c
Compare
|
What is 'DNER'? |
|
It's a shorthand for |
|
Will assume the OSX x64 timeout is not related (I've seen it on quite a few other PRs as well recently). @dotnet/jit-contrib, @tannergooding - fixing one of the asserts that are currently showing up in SPMI in CI (and locally). |
As the added comment states, we must do this to get dependent promotion, as otherwise the compiler does not support independent promotion of structs not fully eliminated from the IR, save some special cases (such as multi-reg structs).
We will only need to do this very rarely, as otherwise we mark SIMD locals used by SIMDs/HWIs specially when creating those nodes so as not to promote them.
This issue was revealed by forward substituion, where we had:
And forward-substituted the promoted "b" into "HWI". Notably, by the time we are forward-substituting, "we cannot really do anything about it", as struct promotion has already run, and by the time we get to morph, we too cannot do much save some gymnastics with conjuring up a tree of inserts from individual fields.
No diffs.
Side note: this is a conservative solution, but is always correct and does not put us in a worse position CQ-wise. It is possible/probable that we can "do better" at marking SIMD locals as "no promotion", or abandoning promotion for them altogether, but that is out of scope for this assert fix.