-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
ARM ABI #14194
ARM ABI #14194
Conversation
// TODO: If the argument is an integral Fundamental Data Type that is | ||
// smaller than a word, then it is zero- or sign-extended to a full word and | ||
// its size is set to 4 bytes. If the argument is a Half-precision Floating | ||
// Point Type it is converted to Single Precision. |
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.
you can return T_int32
and the callee of this function will zero/sign extend to accommodate
i had seen that announcement thread, but that library doesn't actually have a very good or complete ABI implementation and yet contains considerably more code.
afaics, this is only meaningful when applied to byval arguments. if not specified, it defaults to the platform-default value, which should be perfectly suitable for our requirements.
yep, it looks like clang does the following:
|
Thanks for the feedback, @vtjnash, I'll be looking at it. Seems like there's some other places I'm dropping the ball (not generating |
Would have been a good idea to keep this open, and force push to this branch. That way the discussion around the ARM ABI could have continued here. Anyways, it can always a new PR. |
Huh, the delete & close was actually an unintended artifact of a EDIT: done. I'll try not to delete this branch in the future :-) |
Any updates on this one to get it to a state where we can merge it? I have been salivating on this PR for a few days and hoping we can even backport it as well. |
+1 This is an awesome piece of work. Would be great to bring it to conclusion. |
Sorry, haven't had the time to work on this, and I won't for the next few days either. I'll look at it next week, but if anyone is impatient enough to pick this up, be my guest :-) |
As promised, here is a reworked version of this PR. The current version is much more thorough, follows the docs better, and aligns with @yuyichao's recent AArch64 work. It successfully passes my extended version of the @vtjnash |
//===----------------------------------------------------------------------===// | ||
|
||
// LIMITATIONS | ||
// - doesn't respect register usage, these should be encoded in the ABI state |
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 think this is handled by llvm and it should handle it well as long as we emit the correct lowered type.
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 think you're right, I had thought the split register/stack mode would need to be generated by the front-end but it seems part of ARMCallingConv.td.
I haven't fully read the AArch32 calling convension doc yet but I do remember That test is technically wrong for AArch64 since |
Decomposing the |
This should be pretty feature complete now. I guess the homogeneous aggregate detection could be shared between ABI's, like Clang does it, but I don't really feel like tackling that right now. |
Do the commits need squashing? While @vtjnash should review and merge the PR, I am guessing that tests are not necessary here since the failing tests that this PR will fix are sufficient to catch future regressions. |
Yeah, those tests + those from #14215 should cover the ABI sufficiently. Maybe there should be a CI bot for ARM too? Anyway, I'll squash/rebase/remove the RFC tag tomorrow morning. |
On Travis, one has to compile with a cross compiling toolchain and then test in qemu, which is probably really slow. There is a plan to at least set up buildbots that can run every night on a scaleway machine. @staticfloat almost has this going, but currently giving |
|
||
void needPassByRef(AbiState *state,jl_value_t *ty, bool *byRef, bool *inReg) | ||
{ | ||
// B.1 (TODO) |
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 is irrelevant. It doesn't really exist in C and it roughly correspond to our Any
which is indeed passing by pointer.
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.
OK.
|
||
base = NULL; | ||
for (size_t i = 0; i < members; ++i) { | ||
Type *T = isLegalHAType((jl_datatype_t*)jl_field_type(dt,i)); |
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.
And I believe the members counting is wrong for recursive types.
@yuyichao I addressed your comments. Other pending reviews? If not, is this good to go? |
LGTM =) @vtjnash Any comments? If not I'll merge later today. |
Bumping again to see if we can backport to 0.4. Looks like it shouldn't be a difficult backport and fairly self-contained. |
@tkelman As you had mentioned to me, the codegen restructure makes it difficult to have a clean backport to 0.4. Perhaps ARM should just wait for 0.5. |
I thought I phrased it the other way around - anything that depends on the codegen rewrite will obviously be tough to backport on its own, but most of the currently backport-tagged arm-related PR's look more or less standalone? Let's see what ends up being easy to backport for 0.4.4 and how many arm bugs we can fix there without spending too much effort. |
I actually have backported pretty much all of them. There are compile errors in the arm ABI file, because they refer to things that were not in 0.4. |
You introduced a bunch of CI failures. Could you have gone through a PR? |
I never pushed I thought. |
At least I didn't mean to, but might have done it out of habit, when on a branch - except this was the release branch. Can we get rid of them right away? |
Revert the commits that are broken. The release branch is protected so force pushing is disabled. Does release-0.4 compile on arm with llvm 3.7.1? If the new ABI doesn't compile on ARM without the codegen rewrite then that's a regression w.r.t. 0.4.3 so that should probably also be reverted. |
I have reverted locally the arm abi patches. I think the rest should be ok, and this will give a fully functioning build, with llvm 3.7.1. Once I do that successfully, I can push the reverts. |
Hi all,
I wanted to run Julia on my Raspberry Pi 2, so I have taken a stab at implementing an ARM ABI interface for Julia. This fixes the following issues: #13508, #12355, #12347, #12343, and partially fixes #12344 (the
parallel
test suite doesn't pass yet, but the segfaults are fixed).Although I'm happy with how most of Julia now works on my ARM-based computer, I don't think that implementing ABI's in this ad-hoc fashion is really future-proof. I'm sure there's missing features (not caught by the current test suite), and I'm not entirely convinced by the current ABI interface (
needPassByRef
,use_sret
,preferred_llvm_type
etc). Maybe we should look into using llvm-abi (announcement thread), a library for generating ABI-compliant LLVM IR?Some questions/uncertainties:
#error
ing out if not found. I'm not sure if this is appropriate, but the ABI currently relies on this.align
attribute. I don't think this is easy to add without messing withccall
, but it might be a neater way of aligning aggregates.