JIT: Add separate ABI classifiers for x86/win-x64/SysV-x64/ARM64 by jakobbotsch · Pull Request #100276 · dotnet/runtime

jakobbotsch · 2024-03-26T11:36:51Z

While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of lvaInitUserArgs to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI.

ARM32, LA64 and RV64 still need to be split out.

We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within lvaInitUserArgs (and in the long run hopefully CallArgs::AddFinalArgsAndDetermineABIInfo).

Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in lvaSetStruct/getArgTypeForStruct.

SingleAccretion · 2024-03-26T11:45:32Z

+ bool HasRetBuff = false;
+};
+
+class X86Classifier


What do you think about having target-specific classifiers in target-specific files (targetXYZ.cpp, which we already have but don't really use)?

I like that idea. They'll probably have to stay as being defined in abi.h, but I'll try moving the classification Implementation into those target specific files.

For HVAs the element size can be > 8, but should at most be 8-byte aligned.

jakobbotsch · 2024-03-26T18:43:26Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs. Some TP regressions, with some MinOpts outliers in the collections that don't have a lot of MinOpts collections.

…net#100276) While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of `lvaInitUserArgs` to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI. ARM32, LA64 and RV64 still need to be split out. We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within `lvaInitUserArgs` (and in the long run hopefully `CallArgs::AddFinalArgsAndDetermineABIInfo`). Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in `lvaSetStruct`/`getArgTypeForStruct`.

jakobbotsch · 2024-03-26T11:36:51Z

While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of lvaInitUserArgs to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI.

ARM32, LA64 and RV64 still need to be split out.

We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within lvaInitUserArgs (and in the long run hopefully CallArgs::AddFinalArgsAndDetermineABIInfo).

Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in lvaSetStruct/getArgTypeForStruct.

SingleAccretion · 2024-03-26T11:45:32Z

+ bool HasRetBuff = false;
+};
+
+class X86Classifier


What do you think about having target-specific classifiers in target-specific files (targetXYZ.cpp, which we already have but don't really use)?

I like that idea. They'll probably have to stay as being defined in abi.h, but I'll try moving the classification Implementation into those target specific files.

For HVAs the element size can be > 8, but should at most be 8-byte aligned.

jakobbotsch · 2024-03-26T18:43:26Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs. Some TP regressions, with some MinOpts outliers in the collections that don't have a lot of MinOpts collections.

…net#100276) While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of `lvaInitUserArgs` to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI. ARM32, LA64 and RV64 still need to be split out. We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within `lvaInitUserArgs` (and in the long run hopefully `CallArgs::AddFinalArgsAndDetermineABIInfo`). Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in `lvaSetStruct`/`getArgTypeForStruct`.

jakobbotsch · 2024-03-26T11:36:51Z

While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of lvaInitUserArgs to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI.

ARM32, LA64 and RV64 still need to be split out.

We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within lvaInitUserArgs (and in the long run hopefully CallArgs::AddFinalArgsAndDetermineABIInfo).

Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in lvaSetStruct/getArgTypeForStruct.

SingleAccretion · 2024-03-26T11:45:32Z

+ bool HasRetBuff = false;
+};
+
+class X86Classifier


What do you think about having target-specific classifiers in target-specific files (targetXYZ.cpp, which we already have but don't really use)?

I like that idea. They'll probably have to stay as being defined in abi.h, but I'll try moving the classification Implementation into those target specific files.

For HVAs the element size can be > 8, but should at most be 8-byte aligned.

jakobbotsch · 2024-03-26T18:43:26Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs. Some TP regressions, with some MinOpts outliers in the collections that don't have a lot of MinOpts collections.

…net#100276) While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of `lvaInitUserArgs` to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI. ARM32, LA64 and RV64 still need to be split out. We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within `lvaInitUserArgs` (and in the long run hopefully `CallArgs::AddFinalArgsAndDetermineABIInfo`). Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in `lvaSetStruct`/`getArgTypeForStruct`.

jakobbotsch · 2024-03-26T11:36:51Z

While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of lvaInitUserArgs to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI.

ARM32, LA64 and RV64 still need to be split out.

We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within lvaInitUserArgs (and in the long run hopefully CallArgs::AddFinalArgsAndDetermineABIInfo).

Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in lvaSetStruct/getArgTypeForStruct.

SingleAccretion · 2024-03-26T11:45:32Z

+ bool HasRetBuff = false;
+};
+
+class X86Classifier


What do you think about having target-specific classifiers in target-specific files (targetXYZ.cpp, which we already have but don't really use)?

I like that idea. They'll probably have to stay as being defined in abi.h, but I'll try moving the classification Implementation into those target specific files.

For HVAs the element size can be > 8, but should at most be 8-byte aligned.

jakobbotsch · 2024-03-26T18:43:26Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs. Some TP regressions, with some MinOpts outliers in the collections that don't have a lot of MinOpts collections.

…net#100276) While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of `lvaInitUserArgs` to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI. ARM32, LA64 and RV64 still need to be split out. We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within `lvaInitUserArgs` (and in the long run hopefully `CallArgs::AddFinalArgsAndDetermineABIInfo`). Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in `lvaSetStruct`/`getArgTypeForStruct`.

jakobbotsch · 2024-03-26T11:36:51Z

While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of lvaInitUserArgs to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI.

ARM32, LA64 and RV64 still need to be split out.

We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within lvaInitUserArgs (and in the long run hopefully CallArgs::AddFinalArgsAndDetermineABIInfo).

Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in lvaSetStruct/getArgTypeForStruct.

SingleAccretion · 2024-03-26T11:45:32Z

+ bool HasRetBuff = false;
+};
+
+class X86Classifier


What do you think about having target-specific classifiers in target-specific files (targetXYZ.cpp, which we already have but don't really use)?

I like that idea. They'll probably have to stay as being defined in abi.h, but I'll try moving the classification Implementation into those target specific files.

For HVAs the element size can be > 8, but should at most be 8-byte aligned.

jakobbotsch · 2024-03-26T18:43:26Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs. Some TP regressions, with some MinOpts outliers in the collections that don't have a lot of MinOpts collections.

…net#100276) While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of `lvaInitUserArgs` to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI. ARM32, LA64 and RV64 still need to be split out. We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within `lvaInitUserArgs` (and in the long run hopefully `CallArgs::AddFinalArgsAndDetermineABIInfo`). Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in `lvaSetStruct`/`getArgTypeForStruct`.

jakobbotsch · 2024-03-26T11:36:51Z

While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of lvaInitUserArgs to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI.

ARM32, LA64 and RV64 still need to be split out.

We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within lvaInitUserArgs (and in the long run hopefully CallArgs::AddFinalArgsAndDetermineABIInfo).

Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in lvaSetStruct/getArgTypeForStruct.

SingleAccretion · 2024-03-26T11:45:32Z

+ bool HasRetBuff = false;
+};
+
+class X86Classifier


What do you think about having target-specific classifiers in target-specific files (targetXYZ.cpp, which we already have but don't really use)?

I like that idea. They'll probably have to stay as being defined in abi.h, but I'll try moving the classification Implementation into those target specific files.

For HVAs the element size can be > 8, but should at most be 8-byte aligned.

jakobbotsch · 2024-03-26T18:43:26Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs. Some TP regressions, with some MinOpts outliers in the collections that don't have a lot of MinOpts collections.

…net#100276) While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of `lvaInitUserArgs` to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI. ARM32, LA64 and RV64 still need to be split out. We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within `lvaInitUserArgs` (and in the long run hopefully `CallArgs::AddFinalArgsAndDetermineABIInfo`). Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in `lvaSetStruct`/`getArgTypeForStruct`.

jakobbotsch · 2024-03-26T11:36:51Z

While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of lvaInitUserArgs to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI.

ARM32, LA64 and RV64 still need to be split out.

We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within lvaInitUserArgs (and in the long run hopefully CallArgs::AddFinalArgsAndDetermineABIInfo).

Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in lvaSetStruct/getArgTypeForStruct.

SingleAccretion · 2024-03-26T11:45:32Z

+ bool HasRetBuff = false;
+};
+
+class X86Classifier


What do you think about having target-specific classifiers in target-specific files (targetXYZ.cpp, which we already have but don't really use)?

I like that idea. They'll probably have to stay as being defined in abi.h, but I'll try moving the classification Implementation into those target specific files.

For HVAs the element size can be > 8, but should at most be 8-byte aligned.

jakobbotsch · 2024-03-26T18:43:26Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs. Some TP regressions, with some MinOpts outliers in the collections that don't have a lot of MinOpts collections.

…net#100276) While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of `lvaInitUserArgs` to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI. ARM32, LA64 and RV64 still need to be split out. We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within `lvaInitUserArgs` (and in the long run hopefully `CallArgs::AddFinalArgsAndDetermineABIInfo`). Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in `lvaSetStruct`/`getArgTypeForStruct`.

jakobbotsch · 2024-03-26T11:36:51Z

While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of lvaInitUserArgs to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI.

ARM32, LA64 and RV64 still need to be split out.

We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within lvaInitUserArgs (and in the long run hopefully CallArgs::AddFinalArgsAndDetermineABIInfo).

Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in lvaSetStruct/getArgTypeForStruct.

SingleAccretion · 2024-03-26T11:45:32Z

+ bool HasRetBuff = false;
+};
+
+class X86Classifier


What do you think about having target-specific classifiers in target-specific files (targetXYZ.cpp, which we already have but don't really use)?

I like that idea. They'll probably have to stay as being defined in abi.h, but I'll try moving the classification Implementation into those target specific files.

For HVAs the element size can be > 8, but should at most be 8-byte aligned.

jakobbotsch · 2024-03-26T18:43:26Z

cc @dotnet/jit-contrib PTAL @AndyAyersMS

No diffs. Some TP regressions, with some MinOpts outliers in the collections that don't have a lot of MinOpts collections.

…net#100276) While trying to implement struct support for Swift reverse pinvokes I ended up having to factor the ABI classification out of `lvaInitUserArgs` to be able to invoke it multiple times for structs. In the end that led me to do the work to split out the ABI classification into a different classifier for each ABI. ARM32, LA64 and RV64 still need to be split out. We still don't actually use this information for anything, but it's asserted that it is correct. We are going to be using it in the backend for Swift reverse pinvokes, and I expect to move more and more things to use it and get completely rid of the ABI classification within `lvaInitUserArgs` (and in the long run hopefully `CallArgs::AddFinalArgsAndDetermineABIInfo`). Another todo: this classification should be where we determine whether something is passed implicit by reference instead of doing that in `lvaSetStruct`/`getArgTypeForStruct`.

jakobbotsch added 8 commits March 25, 2024 20:05

JIT: Split ABI classification by ABI
fea5284

Refactor, fix arm64
150cb28

Run jit-format
af2fc72

Comments
1d09c9f

Fix varargs retbuf case
dcccedd

Fix SysV
7fe878b

Add function headers
9297865

Nit
25e2c49

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

Fix macOS arm64 ABI bug
9954062

dotnet-policy-serviceBot assigned jakobbotsch Mar 26, 2024

jakobbotsch changed the title ~~JIT: Add separate ABI classifiers for x86/win-x64/SysV x64/ARM64~~JIT: Add separate ABI classifiers for x86/win-x64/SysV-x64/ARM64Mar 26, 2024

SingleAccretion reviewed Mar 26, 2024
View reviewed changes

jakobbotsch added 2 commits March 26, 2024 12:54

Preemptively fix build
5fab654

More build fixes
3f1c738

This was referenced Mar 26, 2024
JIT: Generalize hasFixedRetBuffReg for ARM64 #100277
Merged
JIT: Fix mangleVarArgsType for SIMD types #100278
Merged

jakobbotsch added 5 commits March 26, 2024 13:21

Further fix build
b8d9334

Move classifiers into target specific files
f12a9d7

Fix x86
70a0aff

Fix Apple ARM64 ABI for HVAs
0e82029
For HVAs the element size can be > 8, but should at most be 8-byte aligned.

Merge branch 'main' of github.com:dotnet/runtime into split-abis
931e2e5

jakobbotsch requested a review from AndyAyersMS March 26, 2024 18:43

jakobbotsch marked this pull request as ready for review March 26, 2024 18:44

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

AndyAyersMS approved these changes Mar 29, 2024
View reviewed changes

jakobbotsch merged commit 10e87bc into dotnet:mainApr 2, 2024

jakobbotsch deleted the split-abis branch April 2, 2024 08:30

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 May 2, 2024