Enable TYP_STRUCT LCL_VAR/LCL_FLD call args on ARM

[SingleAccretion]

Enables the folding for our last target.

As usual, we have diffs, mostly improvements, but there is one kind of regression unique to ARM.

It happens when we forward-substitute a promoted struct local as a non-first parameter. On ARM, we copy promoted struct arguments into outgoing temps, which then means we copy things before it in the parameter list:

CALL
    ARG_1
    ARG_2<promoted LCL_VAR>

    ==>

CALL
    ASG
       LCL_VAR arg1temp
       ARG_1
    COMMAs<field assignments for ARG_2>
    LCL_VAR arg1temp
    LCL_VAR arg2temp

Where without forward subtituion we would have:

COMMAs<field assignments for ARG_2>

CALL
    ARG_1
    ARG_2

The right fix for this is to drop the copying of promoted temps; and I have the changes necessary for that ready (#71780); we can decide if it's important to wait for them, or ok to merge this PR as-is.

Also we have some regressions in test methods with huge structs and on non-ARM platforms from the last commit.

[ghost]

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

Issue Details

---

Enables the folding for our last target.

As usual, we have diffs, mostly improvements, but there is one kind of regression unique to ARM.

It happens when we forward-substitute a promoted struct local as a non-first parameter. On ARM, we copy promoted struct arguments into outgoing temps, which then means we copy things before it in the parameter list:

CALL
    ARG_1
    ARG_2<promoted LCL_VAR>

    ==>

CALL
    ASG
       LCL_VAR arg0temp
       ARG_1
    COMMAs<field assignments for ARG_2>
    LCL_VAR arg0temp
    LCL_VAR arg1temp

Where without forward subtituion we would have:

COMMAs<field assignments for ARG_2>

CALL
    ARG_1
    ARG_2

The right fix for this is to drop the copying of promoted temps; and I have the changes necessary for that ready (the first is #71399, then there will be two more), and we can decide it's important to wait them, or it is ok to merge this PR as-is.

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

[SingleAccretion]

@dotnet/jit-contrib

[jakobbotsch]

The right fix for this is to drop the copying of promoted temps; and I have the changes necessary for that ready (#71780); we can decide if it's important to wait for them, or ok to merge this PR as-is.

Is this just one PR away now?

[SingleAccretion]

Is this just one PR away now?

Yep.

Edit: barring unforeseen bugs, etc.

[jakobbotsch]

Ah, just saw #71780. Let's wait for that one then, those diffs did look a bit scary even if they were in some unrealistic test cases.

[jakobbotsch]

/azp run runtime-coreclr superpmi-diffs

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jakobbotsch]

Looks like there are still some large regressions in those tests. Unexpected?

[SingleAccretion]

Unexpected?

It's the same issue as in #70861 - 11K struct sources for PUTARG_SPLITs.

[jakobbotsch]

It's the same issue as in #70861 - 11K struct sources for PUTARG_SPLITs.

Ok, seems fine then.