-
Notifications
You must be signed in to change notification settings - Fork 214
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
__aeabi_ functions should use the AAPCS calling convention, at least with LLVM 4.0+ #116
Comments
Is there a better way to solve this than using a macro for every |
Yes or we'll hit the floatundidf bug when we integrate this into rust-lang/rust.
The "aliased" functions must also use extern "aapcs" This may me realize that we may be invoking the functions in libcompiler-rt.a with the wrong calling convention. We are calling them as if they were |
To clarify: I meant in our unit tests. We have a transmute from |
Yes, this seems very likely to be causing #90 and the issues in #106.
If I recall correctly, the issues only occurred inside the unit tests not when called normally, which makes sense. I'll go test this theory right now. |
I tested this by making everything https://github.com/mattico/compiler-builtins/tree/aapcs |
I don't think changes like these are correct:
I think the intrinsics in libgcc.a are compiled the "hard" calling convention (not aapcs) so those should be called using |
From the discussion above, I gather:
|
Note that for rust currently Af far as I can tell, in Rust there is currently no way to specify The only thing that changes for llvm 4.0, I think, is that the |
Does
It's not clear to me whether that is a regression or improvement. I think it's regression but the compiler-rt guy thinks that's how it should be. |
No, from the rust source:
|
Is that a bug? With that |
Well, there's the comment I would assume that this was the easy way of getting the correct aapcs version (soft vs hard float) without having to add that logic to rustc. |
Yes definitely a bug and the reason the @mattico's test failed. |
Bug report here rust-lang/rust#37810 |
@mattico FYI: |
also, on ARM, inline(always) the actual implementation of the intrinsics so we end with code like this: ``` 00000000 <__aeabi_dadd>: (implementation here) ``` instead of "trampolines" like this: ``` 00000000 <__aeabi_dadd>: (shuffle registers) (call __adddf3) 00000000 <__adddf3>: (implementation here) ``` closes #116
use AAPCS calling convention on all aeabi intrinsics also, on ARM, inline(always) the actual implementation of the intrinsics so we end with code like this: ``` 00000000 <__aeabi_dadd>: (implementation here) ``` instead of "trampolines" like this: ``` 00000000 <__aeabi_dadd>: (shuffle registers) (call __adddf3) 00000000 <__adddf3>: (implementation here) ``` closes #116 cc #66 r? @alexcrichton cc @mattico
use AAPCS calling convention on all aeabi intrinsics also, on ARM, inline(always) the actual implementation of the intrinsics so we end with code like this: ``` 00000000 <__aeabi_dadd>: (implementation here) ``` instead of "trampolines" like this: ``` 00000000 <__aeabi_dadd>: (shuffle registers) (call __adddf3) 00000000 <__adddf3>: (implementation here) ``` closes #116 cc #66 r? @alexcrichton cc @mattico
The purpose of this branch is to switch to using an object file for each independent function, in order to make linking simpler - instead of relying on `-ffunction-sections` and `--gc-sections`, which involves the linker doing the work of linking everything and then undoing work via garbage collection, this will allow the linker to only include the compilation units that are depended on in the first place. This commit makes progress towards that goal.
On arm, llvm treats the C calling convention as `aapcs` on soft-float targets and `aapcs-vfp` on hard-float targets [1]. UEFI specifies in the arm calling convention that floating point extensions aren't used [2], so always translate `efiapi` to `aapcs` on arm. [1]: rust-lang/compiler-builtins#116 (comment) [2]: https://uefi.org/specs/UEFI/2.10/02_Overview.html#detailed-calling-convention rust-lang#65815
…r=nagisa Use aapcs for efiapi calling convention on arm On arm, [llvm treats the C calling convention as `aapcs` on soft-float targets and `aapcs-vfp` on hard-float targets](rust-lang/compiler-builtins#116 (comment)). UEFI specifies in the arm calling convention that [floating point extensions aren't used](https://uefi.org/specs/UEFI/2.10/02_Overview.html#detailed-calling-convention), so always translate `efiapi` to `aapcs` on arm. rust-lang#65815
…r=nagisa Use aapcs for efiapi calling convention on arm On arm, [llvm treats the C calling convention as `aapcs` on soft-float targets and `aapcs-vfp` on hard-float targets](rust-lang/compiler-builtins#116 (comment)). UEFI specifies in the arm calling convention that [floating point extensions aren't used](https://uefi.org/specs/UEFI/2.10/02_Overview.html#detailed-calling-convention), so always translate `efiapi` to `aapcs` on arm. rust-lang#65815
I'm not exactly sure about the specifics of this issue but based on
rust-lang/compiler-rt#26 (comment)
I think the __aeabi aliases should use the AAPCS calling convention.
extern "aapcs" fn
seems to work. If the functions that are being aliased don't also useextern "aapcs"
there may be some shuffling around of registers which may hamper inlining.The text was updated successfully, but these errors were encountered: