Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 13 commits into from

Conversation

jakobbotsch
Copy link
Member

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.

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Sep 13, 2023
@ghost ghost assigned jakobbotsch Sep 13, 2023
@ghost
Copy link

ghost commented Sep 13, 2023

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
Copy link
Member Author

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
Copy link
Member Author

cc @dotnet/jit-contrib

- Allow GT_IL_OFFSET, GT_NOP
- Skip OSR locals that won't be in registers
- Make use of pointer-size alignment for frame allocations
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant