JIT: [experiment] Add an explicit IR representation for parameter definitions #92026
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
GT_GETPARAM_REG
node that represents the use of an incoming parameter register. It has similar semantics toLCL_VAR
in that it is used at its user, and it does not induce any defs. MultipleGT_GETPARAM_REG
uses for the same parameter is supported.GT_GETPARAM_REG
is only legal in the entry basic block.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.GT_GETPARAM_REG
. This allows physically promoted struct parameters to stay in registers without spills.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 theseGT_GETPARAM_REG
nodes. Spilling support would require some new way to communicate to the backend that the parameter should be spilled during prolog generation.