Remove GT_PUTARG_TYPE

[jakobbotsch]

This change removes GT_PUTARG_TYPE by consistently storing the signature type of the argument inside CallArg right away when arguments are added, instead of only from morph and on.

Diffs are from the following:

• We sometimes do new forward subs now since no GT_PUTARG_TYPE means we have fewer nodes.
• Previously, it was possible with nested inlining to introduce redundant GT_PUTARG_TYPE nodes, in particular when the inliner substituted a single-use local directly for the argument. This would introduce some unnecessary casts and no longer happens.
• We now consistently call gtFoldExpr for args to calls that are inline candidates, even if we back out of the inline. Previously this would happen in some cases (due to bashing) and in some cases not (because we did not write the folded node pointer back to the CallArgs list)

There are a lot of follow-up cleanups to be done, in particular it is now no longer necessary to have morph obtain the class handle from the arg nodes which should simplify some of that code. But I will leave that for a future change.

Based on #68736

[ghost]

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

Issue Details

---

This change removes GT_PUTARG_TYPE by consistently storing the signature type/ABI type of the argument inside CallArgABIInformation right away when arguments are added, instead of only from morph and on.

Diffs are from the following:

• We sometimes do new forward subs now since no GT_PUTARG_TYPE means we have fewer nodes.
• Previously, it was possible with nested inlining to introduce redundant GT_PUTARG_TYPE nodes, in particular when the inliner substituted a single-use local directly for the argument. This would introduce some unnecessary casts and no longer happens.
• We now consistently call gtFoldExpr for args to calls that are inline candidates, even if we back out of the inline. Previously this would happen in some cases (due to bashing) and in some cases not (because we did not write the folded node pointer back to the CallArgs list)

There are a lot of follow-up cleanups to be done, in particular it is now no longer necessary to have morph obtain the class handle from the arg nodes which should simplify some of that code. But I will leave that for a future change.

Based on #68736

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

[jakobbotsch]

/azp run runtime-coreclr jitstress, runtime-coreclr outerloop, runtime-coreclr libraries-jitstress, Fuzzlyn

[azure-pipelines]

Azure Pipelines successfully started running 4 pipeline(s).

[jakobbotsch]

Fuzzlyn issues are preexisting.
win-arm64 and win-arm failures are dotnet/arcade#9284.
jitstress linux-arm and linux-arm64 failures are #68690.
libraries-jitstress linux-arm64 failures look like #68513, #68756.

cc @dotnet/jit-contrib PTAL @AndyAyersMS -- this should be ready for review.
I did wonder if we should include a ClassLayout* instead of the signature class handle, potentially adding methods to make it useful for ABI purposes, but after looking at the code that will end up using it to begin with I just went with the class handle.

[jakobbotsch]

This is a zero-diff change against current main with forward sub disabled and the following patches applied:
https://github.com/dotnet/runtime/compare/main...jakobbotsch:remove-GT_PUTARG_TYPE-zero-diff-target?expand=1

[AndyAyersMS]

I did wonder if we should include a ClassLayout* instead of the signature class handle,

I would like to see us head this way over time—that is, remove most/all direct class handle references from the jit—so we can represent things like boxed value types that won't have class handles.

[AndyAyersMS]

Nice to see this get removed.

[AndyAyersMS]

Wasn't clear to me exactly what "this quirk" is referring to.

[jakobbotsch]

I probably shouldn't call it a quirk, but we currently store the argument's class handle instead of the signature's class handle in CallArg::m_signatureClsHnd. They are different in some cases, e.g. when inlining shared code where the inlining function has exact types. This todo is about storing the actual signature type (returned by the EE) instead of the argument's type. It's probably one of the first follow-ups I'll have after this PR so I'll avoid churning CR to clarify (unless there's other feedback).