JIT: Add a uniform representation for parameter ABI information by jakobbotsch · Pull Request #100138 · dotnet/runtime

jakobbotsch · 2024-03-22T12:36:04Z

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-policy-service · 2024-03-22T12:36:38Z

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

jakobbotsch · 2024-03-25T10:38:02Z

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.

tannergooding · 2024-03-25T15:28:31Z

+ bool IsPassedInRegister() const;
+ bool IsPassedOnStack() const;


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

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.

tannergooding · 2024-03-25T15:47:37Z

+ // - On arm64/arm32, HFAs can be passed in up to four registers, giving
+ // four register segments


This should also include HVAs, which looks like we might be missing handling around:
godbolt HFA/HVA for Arm64
godbolt HVA/HVA for x64

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

AndyAyersMS

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.

jakobbotsch · 2024-03-22T12:36:04Z

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-policy-service · 2024-03-22T12:36:38Z

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

jakobbotsch · 2024-03-25T10:38:02Z

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.

tannergooding · 2024-03-25T15:28:31Z

+ bool IsPassedInRegister() const;
+ bool IsPassedOnStack() const;


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

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.

tannergooding · 2024-03-25T15:47:37Z

+ // - On arm64/arm32, HFAs can be passed in up to four registers, giving
+ // four register segments


This should also include HVAs, which looks like we might be missing handling around:
godbolt HFA/HVA for Arm64
godbolt HVA/HVA for x64

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

AndyAyersMS

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.

jakobbotsch · 2024-03-22T12:36:04Z

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-policy-service · 2024-03-22T12:36:38Z

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

jakobbotsch · 2024-03-25T10:38:02Z

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.

tannergooding · 2024-03-25T15:28:31Z

+ bool IsPassedInRegister() const;
+ bool IsPassedOnStack() const;


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

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.

tannergooding · 2024-03-25T15:47:37Z

+ // - On arm64/arm32, HFAs can be passed in up to four registers, giving
+ // four register segments


This should also include HVAs, which looks like we might be missing handling around:
godbolt HFA/HVA for Arm64
godbolt HVA/HVA for x64

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

AndyAyersMS

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.

jakobbotsch · 2024-03-22T12:36:04Z

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-policy-service · 2024-03-22T12:36:38Z

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

jakobbotsch · 2024-03-25T10:38:02Z

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.

tannergooding · 2024-03-25T15:28:31Z

+ bool IsPassedInRegister() const;
+ bool IsPassedOnStack() const;


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

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.

tannergooding · 2024-03-25T15:47:37Z

+ // - On arm64/arm32, HFAs can be passed in up to four registers, giving
+ // four register segments


This should also include HVAs, which looks like we might be missing handling around:
godbolt HFA/HVA for Arm64
godbolt HVA/HVA for x64

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

AndyAyersMS

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.

jakobbotsch · 2024-03-22T12:36:04Z

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-policy-service · 2024-03-22T12:36:38Z

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

jakobbotsch · 2024-03-25T10:38:02Z

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.

tannergooding · 2024-03-25T15:28:31Z

+ bool IsPassedInRegister() const;
+ bool IsPassedOnStack() const;


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

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.

tannergooding · 2024-03-25T15:47:37Z

+ // - On arm64/arm32, HFAs can be passed in up to four registers, giving
+ // four register segments


This should also include HVAs, which looks like we might be missing handling around:
godbolt HFA/HVA for Arm64
godbolt HVA/HVA for x64

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

AndyAyersMS

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.

jakobbotsch · 2024-03-22T12:36:04Z

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-policy-service · 2024-03-22T12:36:38Z

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

jakobbotsch · 2024-03-25T10:38:02Z

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.

tannergooding · 2024-03-25T15:28:31Z

+ bool IsPassedInRegister() const;
+ bool IsPassedOnStack() const;


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

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.

tannergooding · 2024-03-25T15:47:37Z

+ // - On arm64/arm32, HFAs can be passed in up to four registers, giving
+ // four register segments


This should also include HVAs, which looks like we might be missing handling around:
godbolt HFA/HVA for Arm64
godbolt HVA/HVA for x64

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

AndyAyersMS

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.

jakobbotsch · 2024-03-22T12:36:04Z

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-policy-service · 2024-03-22T12:36:38Z

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

jakobbotsch · 2024-03-25T10:38:02Z

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.

tannergooding · 2024-03-25T15:28:31Z

+ bool IsPassedInRegister() const;
+ bool IsPassedOnStack() const;


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

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.

tannergooding · 2024-03-25T15:47:37Z

+ // - On arm64/arm32, HFAs can be passed in up to four registers, giving
+ // four register segments


This should also include HVAs, which looks like we might be missing handling around:
godbolt HFA/HVA for Arm64
godbolt HVA/HVA for x64

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

AndyAyersMS

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.

jakobbotsch · 2024-03-22T12:36:04Z

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-policy-service · 2024-03-22T12:36:38Z

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

jakobbotsch · 2024-03-25T10:38:02Z

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.

tannergooding · 2024-03-25T15:28:31Z

+ bool IsPassedInRegister() const;
+ bool IsPassedOnStack() const;


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

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.

tannergooding · 2024-03-25T15:47:37Z

+ // - On arm64/arm32, HFAs can be passed in up to four registers, giving
+ // four register segments


This should also include HVAs, which looks like we might be missing handling around:
godbolt HFA/HVA for Arm64
godbolt HVA/HVA for x64

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

AndyAyersMS

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.

jakobbotsch added 2 commits March 22, 2024 13:24

Move method back
af61b2c

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label Mar 22, 2024

dotnet-policy-serviceBot assigned jakobbotsch Mar 22, 2024

This was referenced Mar 22, 2024
Build linux-x64 Debug Mono_MiniJIT_LibrariesTests failure #99942
Closed
Assert failure(PID 13812 [0x000035f4], Thread: 14128 [0x3730]): promoted_bytes (heap_number) == promoted #100035
Closed
Assertion failed: (GetComponentSize() <= 2) || IsArray() #86273
Closed

jakobbotsch added 7 commits March 23, 2024 16:58

Fix x86
9cfbbf5

Number of fixes; revert some changes to make diffable
bb247be

Another fix
aedbcd8

Fix compilation
a5e24a0

Handle retbuf on stack for x86
8adac9e

Merge branch 'main' of github.com:dotnet/runtime into refactor-abi
7cc33d8

Run jit-format
cda86e1

jakobbotsch marked this pull request as ready for review March 25, 2024 10:35

jakobbotsch requested a review from AndyAyersMS March 25, 2024 10:42

tannergooding reviewed Mar 25, 2024
View reviewed changes

AndyAyersMS approved these changes Mar 25, 2024
View reviewed changes

jakobbotsch merged commit 13a9036 into dotnet:mainMar 25, 2024

jakobbotsch deleted the refactor-abi branch March 25, 2024 17:34

jakobbotsch mentioned this pull request Mar 27, 2024
JIT: Add support for frozen structs in Swift reverse pinvokes #100344
Merged
1 task

jakobbotsch mentioned this pull request Apr 7, 2024
JIT: Add missing new-style ABI classifiers for LA64 and RISCV64 #100744
Closed

github-actionsBot locked and limited conversation to collaborators Apr 25, 2024