ZeroObj assertions

[SingleAccretion]

It is the case that the IR supports the "zero" node for structs in two positions: on the RHS of an assignment (InitBlk form) and under a return, in case the ABI return type is scalar.

Meanwhile, assertion propagation "blindly" replaced structs with zeroes, and so workarounds had to be applied in order for the IR to remain valid, in the form of the NO_CSE flag, applied either explicitly (multi-reg returns) or implicitly (ADDR(LCL) created by impNormStructVal for call args).

This was:

a) A CQ problem in cases where we forgot to clear the NO_CSE flag when the node's parent was updated, say after inlining.
b) A burden for enabling struct LCL_VAR arguments, as one had to remember to mark them NO_CSE in all situations.

This change fixes the problem by deleting propagation of zeroes for local uses, instead propagating them as part of their parents (ASGs and RETURNs).

This has the CQ benefits of not being affected by stale NO_CSEs and the drawback of not participating in the "chained" propagation, where we first copy-propagated something, and then zero-propagated into the new local as well. These cases seem rather rare, so I decided not to spend TP on fixing them by looking at the copy assertions in the new code.

This change also deletes the zero propagation code for SIMDs. It was only useful in cases we had a promoted SIMD field that was zero-inited via an InitBlk on the parent struct. That promotion code was (and is) creating nodes that look like integral constants, except they are of TYP_SIMD. We should delete that form and use proper SIMD zero nodes instead, and design the propagation story for them separately.

I have considered introducing a new flag for this, say GTF_VAR_ZERO_STRUCT_PROP_ALLOWED, to be set on nodes under parents that support "zero" operands, but it seemed like a less robust (if technically "easier") solution to me.

Diffs.

Contributes to #51569.

[ghost]

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

Issue Details

---

It is the case that the IR supports the "zero" node for structs in two positions: on the RHS of an assignment (InitBlk form) and under a return, in case the ABI return type is scalar.

Meanwhile, assertion propagation "blindly" replaced structs with zeroes, and so workarounds had to be applied in order for the IR to remain valid, in the form of the NO_CSE flag, applied either explicitly (multi-reg returns) or implicitly (ADDR(LCL) created by impNormSturctVal for call args).

This was:

a) A CQ problem in cases where we forgot to clear the NO_CSE flag when the node's parent was updated, say after inlining.
b) A burden for enabling struct LCL_VAR arguments, as one had to remembered to mark them NO_CSE in all situation.

This change fixes the problem by deleting propagation of zeroes for local uses, instead propagating them as part of their parents (ASGs and RETURNs).

This has the CQ benefits of not being affected by stale NO_CSEs and the drawback of not participating in the "chained" propagation, where we first copy-propagated something, and then zero-propagated into the new local as well. These cases seem rather rare, so I decided not to spend TP on fixing them by looking at the copy assertions in the new code.

This change also deletes the zero propagation code for SIMDs. It was only useful in cases we had a promoted SIMD field that was zero-inited via an InitBlk on the parent struct. That promotion code was (and is) creating nodes that look like integral constants, except they are of TYP_SIMD. We should delete that form and use proper SIMD zero nodes instead, and design the propagation story for them separately.

Author:	SingleAccretion
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[SingleAccretion]

@dotnet/jit-contrib

[AndyAyersMS]

/azp run runtime

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[AndyAyersMS]

Arm64 build issue is fixed, so rerunning CI.

[AndyAyersMS]

CI issues, restarted some things.