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: Add a uniform representation for parameter ABI information #100138

Merged
merged 9 commits into from
Mar 25, 2024

Conversation

jakobbotsch
Copy link
Member

This adds a uniform representation that can represent the ABI
information for all of our targets without needing to fall back to
handling ABI specific details in all places that need to handle calling
conventions.

Currently nothing is using this information. I want to incrementally
migrate our ABI handling to use this representation. Also, there are
several potential future improvements:

  • Split out ABI classification per ABI instead of keeping them all
    within the same function
  • Unify InitVarDscInfo::stackArgSize and InitVarDscInfo::argSize. I
    am unsure why the latter is needed
  • Remove LclVarDsc::GetArgReg(), LclVarDscInfo::GetOtherArgReg(),
    HFA related members
  • Reuse the representation in CallArgABIInformation and unify the
    classifiers

The end goal here is rewriting genFnPrologCalleeRegArgs to handle
float and integer registers simultaneously, and to support some of the
registers that the Swift calling convention is using.

This adds a uniform representation that can represent the ABI
information for all of our targets without needing to fall back to
handling ABI specific details in all places that need to handle calling
conventions.

Currently nothing is using this information. I want to incrementally
migrate our ABI handling to use this representation. Also, there are
several potential future improvements:

- Split out ABI classification per ABI instead of keeping them all
  within the same function
- Unify `InitVarDscInfo::stackArgSize` and `InitVarDscInfo::argSize`. I
  am unsure why the latter is needed
- Remove `LclVarDsc::GetArgReg()`, `LclVarDscInfo::GetOtherArgReg()`,
  HFA related members
- Reuse the representation in `CallArgABIInformation` and unify the
  classifiers

The end goal here is rewriting `genFnPrologCalleeRegArgs` to handle
float and integer registers simultaneously, and to support some of the
registers that the Swift calling convention is using.
@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 Mar 22, 2024
Copy link
Contributor

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

@jakobbotsch jakobbotsch marked this pull request as ready for review March 25, 2024 10:35
@jakobbotsch
Copy link
Member Author

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs. Some minor TP regressions (the seemingly large MinOpts ones are in collections with < 10 MinOpts contexts).

There's a lot more clean up to be done based on this, but I initially want to use this to represent the ABI details for the structs in Swift reverse pinvokes.

Comment on lines +12 to +13
bool IsPassedInRegister() const;
bool IsPassedOnStack() const;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it relevant to track the other common qualifications like HFA and HVA?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. HFA's/HVA's are just passed in more registers than other struct arguments, so hopefully by the end of this clean up that's a detail that's constrained fully to be within the ABI classification and not leaked out anywhere to the rest of the JIT.

Comment on lines +43 to +44
// - On arm64/arm32, HFAs can be passed in up to four registers, giving
// four register segments
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should also include HVAs, which looks like we might be missing handling around:

godbolt HFA/HVA for Arm64

godbolt HVA/HVA for x64

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are just examples to indicate examples of the representation. The intention of this PR is not to make any functional changes.

Copy link
Member

@AndyAyersMS AndyAyersMS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like a good start...

@jakobbotsch jakobbotsch merged commit 13a9036 into dotnet:main Mar 25, 2024
110 checks passed
@jakobbotsch jakobbotsch deleted the refactor-abi branch March 25, 2024 17:34
jakobbotsch added a commit that referenced this pull request Apr 5, 2024
This adds the final support for frozen structs in UCO methods.

This passes 2500 auto generated tests locally on both macOS x64 and arm64. This
PR includes only 100 tests.

Frozen struct parameters are handled via the new ABI representation added in
#100138. When such a parameter exists we always allocate space for it on the
local stack frame. The struct is then reassembled from its passed constituents
as the first thing in the codegen.

One complication is that there can be an arbitrary amount of codegen to handle
this reassembling. We cannot handle an arbitrary amount of codegen in the
prolog, so the reassembling is handled in two places. First, since the amount of
register passed data is limited, we handle those in the prolog (which frees them
up to be used for other things). If some pieces were passed on the stack the JIT
then ensures that there is a scratch BB and generates the code to reassemble the
remaining parts as the first thing in the scratch BB.

Since Swift structs can be passed by reference in certain cases this PR also
enables `FEATURE_IMPLICIT_BYREFS` for SysV x64 to handle those cases. Depending
on the TP impact we can refine some of the ifdefs around this.
@github-actions github-actions bot locked and limited conversation to collaborators Apr 25, 2024
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.

3 participants