JIT: [experiment] Add an explicit IR representation for parameter definitions

[jakobbotsch]

For the hackathon I have been working on adding an explicit IR representation for parameters that are passed in registers. That is, lowering actually materializes IR to move the parameter register into its local home. The benefit is that this decouples multireg parameter support from promotion, and it can give a more natural way to handle structs with fields that don't cleanly map to the registers.

• Add a GT_GETPARAM_REG node that represents the use of an incoming parameter register. It has similar semantics to LCL_VAR in that it is used at its user, and it does not induce any defs. Multiple GT_GETPARAM_REG uses for the same parameter is supported. GT_GETPARAM_REG is only legal in the entry basic block.
• Add LclVarDsc::lvExplicitParamInit. When a parameter local is marked at such it is not implicitly defined during prolog codegen and behaves essentially like a normal local.
• Add a transform in lowering that converts relevant parameters to this representation, in particular introducing the explicit defs, plus converting additional opportunities into GT_GETPARAM_REG. This allows physically promoted struct parameters to stay in registers without spills.
• Add a new type of interval in LSRA to represent these parameter registers. These intervals are built for each register for each LclVarDsc::lvExplicitParamInit parameter and get the normal parameter def that the local would get. GT_GETPARAM_REG nodes are translated to uses on these intervals. In this experiment these intervals do not support spilling, which puts constraints on what the entry BB is allowed to do with these GT_GETPARAM_REG nodes. Spilling support would require some new way to communicate to the backend that the parameter should be spilled during prolog generation.

[ghost]

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

Issue Details

---

For the hackathon I have been working on adding an explicit IR representation for parameters that are passed in registers. That is, lowering actually materializes IR to move the parameter register into its local home. The benefit is that this decouples multireg parameter support from promotion, and it can give a more natural way to handle structs with fields that don't cleanly map to the registers.

• Add a GT_GETPARAM_REG node that represents the use of an incoming parameter register. It has similar semantics to LCL_VAR in that it is used at its user, and it does not induce any defs. Multiple GT_GETPARAM_REG uses for the same parameter is supported. GT_GETPARAM_REG is only legal in the entry basic block.
• Add LclVarDsc::lvExplicitParamInit. When a parameter local is marked at such it is not implicitly defined during prolog codegen and behaves essentially like a normal local.
• Add a transform in lowering that converts relevant parameters to this representation, in particular introducing the explicit defs, plus converting additional opportunities into GT_GETPARAM_REG. This allows physically promoted struct parameters to stay in registers without spills.
• Add a new type of interval in LSRA to represent these parameter registers. These intervals are built for each register for each LclVarDsc::lvExplicitParamInit parameter and get the normal parameter def that the local would get. GT_GETPARAM_REG nodes are translated to uses on these intervals. In this experiment these intervals do not support spilling, which puts constraints on what the entry BB is allowed to do with these GT_GETPARAM_REG nodes. Spilling support would require some new way to communicate to the backend that the parameter should be spilled during prolog generation.

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

[jakobbotsch]

Overall my current impression is that it would be much simpler to create some new locals instead and communicate to LSRA that these should represent the parameter registers. Then we don't need to introduce a new kind of interval, and things like spilling falls out more or less naturally. On the other hand they will end up taking up slots in local table and tracking indices, and I'm not sure the approach scales to multireg returning calls where I was planning on trying a similar approach.

[jakobbotsch]

cc @dotnet/jit-contrib