[LoongArch64] JIT/EE interface for getting ABI-info

[shushanhf]

add ToolBox directory about jitinterace for getting ABI-info.

[ghost]

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

Issue Details

---

add ToolBox directory about jitinterace for getting ABI-info.

Author:	shushanhf
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[jkotas]

Could you please add links to the LoongArch64 calling convention spec to https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/clr-abi.md as part of this PR?

[shushanhf]

Could you please add links to the LoongArch64 calling convention spec to https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/clr-abi.md as part of this PR?

OK.
I will upload a new patch for it.

[jkotas]

Is there a spec that describes passing of non-primitive types (e..g struct with multiple fields that the new JIT/EE interface methods are dealing with)? https://github.com/loongson/LoongArch-Documentation/blob/main/docs/LoongArch-ELF-ABI-EN.adoc does not seem to be cover it.

[shushanhf]

Is there a spec that describes passing of non-primitive types (e..g struct with multiple fields that the new JIT/EE interface methods are dealing with)? https://github.com/loongson/LoongArch-Documentation/blob/main/docs/LoongArch-ELF-ABI-EN.adoc does not seem to be cover it.

Sorry for late reponse.
Yes, the english version is a brief version.
As I know the struct passed way is the same with the RISC-V.

Later, I will find or ask where is the full version of the english ABI-spec.

Thanks~

[jkotas]

As I know the struct passed way is the same with the RISC-V.

According to https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf, the rules for RISC-V are:

• Structs with size > 2*pointer_size are passed by reference
• Structs with size <= 2*pointer_size are passed in registers
  • Structs that contain floating point values are passed in floating point registers as long as they are smaller than 2*pointer_size. It extended version of HFAs, even float and double combinations are passed in floating point registers.

If the rules are as simple as this, then I think the JIT/EE interface change can be simplified a lot. I think it can be just a single flag that says whether the struct is passed in floating point registers. It should be possible to infer the rest through existing APIs. Thoughts?

[shushanhf]

As I know the struct passed way is the same with the RISC-V.

According to https://riscv.org/wp-content/uploads/2015/01/riscv-calling.pdf, the rules for RISC-V are:

• Structs with size > 2*pointer_size are passed by reference

• Structs with size <= 2*pointer_size are passed in registers

  • Structs that contain floating point values are passed in floating point registers as long as they are smaller than 2*pointer_size. It extended version of HFAs, even float and double combinations are passed in floating point registers.

If the rules are as simple as this, then I think the JIT/EE interface change can be simplified a lot. I think it can be just a single flag that says whether the struct is passed in floating point registers. It should be possible to infer the rest through existing APIs. Thoughts?

yes, but there are a lot of details.
struct {float a; double b;} is the simplist.
struct {float a; float b;} is passed by two float registers.
struct {float a; float b; float c;} should be passed by integer register while the size<2*8 is not enough.
struct{ struct {float a; float b}; float c} is not passed by float-register.
For the struct {float a; long b} and struct {char a; double b;} , the offset of the float field should be consider.

[jkotas]

This does not need to be uint8_t. The default enum underlying type should work just fine.

[shushanhf]

OK, I will update it by dnderlying type.
Thanks.

[jkotas]

LookupApproxFieldTypeHandle can return null. Is there anything that guarantees it won't return null in this case?

Should this rather use GetFieldTypeHandleThrowing that will load the types as necessary and never return null?

[shushanhf]

Thanks.
You are right.
In fact, we had updated it by using a if (pMethodTable) and it works ok.

[jkotas]

In fact, we had updated it by using a if (pMethodTable) and it works ok.

That's not a correct fix. LookupApproxFieldTypeHandle will return null when the type was not loaded before. Using LookupApproxFieldTypeHandle will lead to non-deterministic behavior - the behavior will depend on whether something else in the program happened to load the type or not.

You should change this code to call GetFieldTypeHandleThrowing.

[shushanhf]

In fact, we had updated it by using a if (pMethodTable) and it works ok.

Yes, this is only a workround way.

That's not a correct fix. LookupApproxFieldTypeHandle will return null when the type was not loaded before. Using LookupApproxFieldTypeHandle will lead to non-deterministic behavior - the behavior will depend on whether something else in the program happened to load the type or not.

You should change this code to call GetFieldTypeHandleThrowing.

Thanks a lot !!!
I will update it.

[jkotas]

@jkotas Do you have further comments on the changes in jitinterface.cpp

The general shape looks fine to me. I have left some additional comments.

[shushanhf]

Hi, @jkotas
I have another question, the funciton getLoongArch64PassStructInRegisterFlags() within the file src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs is unimplement.
Now I implement it but there is a problem for the case of TypeFlags.Class that needs your help.

Should I create a new PR for adding getLoongArch64PassStructInRegisterFlags() ?

[jkotas]

getLoongArch64PassStructInRegisterFlags() within the file src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs is unimplement.

The implementation should be part of this PR.

[shushanhf]

getLoongArch64PassStructInRegisterFlags() within the file src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs is unimplement.

The implementation should be part of this PR.

OK, I will upload it later.

[shushanhf]

The runtime and SDK for LoongArch64 are based on the 6.0.102 while the sdk-LoongArch64 was made by ourself.

[BruceForstall]

@shushanhf Are there are changes you plan to make in this PR?

We're waiting for this one to be complete, and be merged, before reviewing #62885

[shushanhf]

@shushanhf Are there are changes you plan to make in this PR?

Hi, @BruceForstall
I had finished for this PR.
The crossgen2 for LA64 will be submitted by a new PR later which waiting the CI's SDK supporting LoongArch64 compiling.

Thanks.

We're waiting for this one to be complete, and be merged, before reviewing #62885

[BruceForstall]

I left a couple minor comments.

Plus: you need to change the JIT/EE version in https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/jiteeversionguid.h, since you've changed the interface.

[BruceForstall]

@jkotas Do you have any final comments/requests before this gets merged?

[shushanhf]

I left a couple minor comments.

Plus: you need to change the JIT/EE version in https://github.com/dotnet/runtime/blob/main/src/coreclr/inc/jiteeversionguid.h, since you've changed the interface.

@BruceForstall
Can use the uuidgen command within the linux for generating the UUID ?

[jkotas]

@jkotas Do you have any final comments/requests before this gets merged?

Added a few nits. LGTM otherwise.

[BruceForstall]

@BruceForstall
Can use the uuidgen command within the linux for generating the UUID ?

Hmmm, probably not, but it looks like you figured out how to get a new GUID (or just chose one randomly).