Morph ASG(ONE_FLD_STRUCT, CALL) using BITCAST

[SingleAccretion]

This changes the representation we have for the special case of assignments from calls that return a struct with one field
to a promoted local of that struct type, making it more normal and simplifying the model for SSA and value numbering.

In the past, the optimization phases treated this case specially and "skipped" the outer struct local in relevant cases. Instead, I propose a new form for this assignment: ASG(FLD, BITCAST(CALL)), that gets rid of this special-casing, and introduces the useful invariant that if a node has an SSA name, then it always represents a def or use of the corresponding SSA local.

After optimizations have done their work, lowering removes the new bitcasts as they do not have meaningful value in the backend.

There are some downsides to this representation. For example, if we decide to stop retyping helper calls in the importer, VN will start giving BITCAST VNs to locals assigned values produced by important helpers such as TypeHandleToRuntimeTypeHandle.

It makes the IR a bit larger, and, perhaps more importantly, less dense. I can measure a 0.003% increase in memory consumption when CG-ing x64 CoreLib with this change. There are some TP benefits from the reduced checks too, they may offset this regression (my PIN is too noisy to detect anything though :( ).

I posit that the benefits outweigh the drawbacks in this case.

Part of #58312.

[ghost]

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

Issue Details

---

Let's see what the CI says about this change.

Part of #58312.

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

[SingleAccretion]

There are diffs with this change: win-x64, win-arm64. There are a few sources of them.

1. Detection of candidates for the EH write-thru optimization does not "see" through the struct assignments here:

   runtime/src/coreclr/jit/lclvars.cpp

   Line 4070 in 2a87ffe

   if (tree->gtFlags & GTF_VAR_DEF) // Is this is a def of our variable

   With this change it does, and this causes different register allocation (in all examples I've seen - minor size regressions) as the promoted field is marked "single def for the purposes of EH write-thru".
2. VN-based copy propagation is enabled for the fields. This is a bit counterintuitive - what copy propagation if we see that it already "looks through" the structs and such (and the fields are given VNs)? The reason is that copy propagation checks for the VNs assigned to the LHS of an assignment. Before this change, no VN was assigned to the struct local on the LHS as it was not tracked, thus copy propagation "missed" some defs for the field. One will notice: if the assignment does not update any VNs, then how come the SSA def for the field gets assigned a VN after all? The answer is in the code here, which does "see through" the struct local, and assigns the per-SSA-def-VN in question. I believe this path can be deleted now (it just allocates unnecessary unique VNs that will be overwritten when numbering the assignment anyway). I did not do it in this PR though - not worth the risk.
3. CSE and folding kicking in for analyzable results of helper calls. This one is pretty straightforward - if we can VN the call source for the bitcast, we can also properly VN the field - recall that before this change all such definitions were given unique VNs. However, it seems that we retype the helpers to primitives anyway, so this does not have as much of an impact (a few cases here and there involving CORINFO_HELP_TYPEHANDLE_TO_RUNTIMETYPEHANDLE).
4. Loop cloning misses definitions for fields of promoted structs #61040 - we now (correctly) see the promoted field as not invariant in the loop and give up on eliminating the bounds check, either statically (size regressions) or via cloning (size improvements). These are the "big" diffs in libraries - we have surprisingly many of them.

[SingleAccretion]

Will leave this as a draft for now pending #61040 being fixed, to reduce the noise in the diffs.

Edit: now with #61040 fixed, it is perhaps time to finally get back to this..

[ghost]

This pull request has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

[JulieLeeMSFT]

@SingleAccretion, I marked this PR as .NET 8. If you think it should be .NET 7, please let me know.