-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Conversation
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.
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
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. |
bool IsPassedInRegister() const; | ||
bool IsPassedOnStack() const; |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
// - On arm64/arm32, HFAs can be passed in up to four registers, giving | ||
// four register segments |
There was a problem hiding this comment.
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:
There was a problem hiding this comment.
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.
There was a problem hiding this 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...
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.
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:
within the same function
InitVarDscInfo::stackArgSize
andInitVarDscInfo::argSize
. Iam unsure why the latter is needed
LclVarDsc::GetArgReg()
,LclVarDscInfo::GetOtherArgReg()
,HFA related members
CallArgABIInformation
and unify theclassifiers
The end goal here is rewriting
genFnPrologCalleeRegArgs
to handlefloat and integer registers simultaneously, and to support some of the
registers that the Swift calling convention is using.