This is restricted version of patch - https://reviews.llvm.org/D33205
that I reverted as it was leading to ABI breaks on darwin etc.
This patch restricts the fix to AAPCS only.
Details
Diff Detail
Event Timeline
test/CodeGen/neon-aapcs-align.c | ||
---|---|---|
10 | Can you make sure that an Android triple doesn't trigger this? I worry because I am not sure what getABI() will return in that case. |
test/CodeGen/neon-aapcs-align.c | ||
---|---|---|
10 | Could you please elaborate.There is a test already 'armv7-none-linux-androideabi'. lib/Basic/Targets.cpp:5357:: case llvm::Triple::Android: |
LGTM
test/CodeGen/neon-aapcs-align.c | ||
---|---|---|
10 | Yes, but you are also passing -target-abi here. I wanted confirmation that this will always be passed on the cc1 line. I think the line from Targets.cpp confirms that this is going to be the case (unless someone explicitly passes a different -target-abi option to cc1. Thanks. |
It certainly seems more restrictive than the previous patch, so I think it should be ok. @rengolin probably understands the subtleties here a bit better than I do.
test/CodeGen/neon-aapcs-align.c | ||
---|---|---|
10 | This is odd. On Android alone, it should be 128. In anything + aapcs, it should be 64, including Android. Explicit behaviour trumps default behaviour. Do we have tests to make sure that the right CC1 flags are passed down? We need two types of tests here: default behaviour and overriden behaviour. I'd also add a GNUEABI and FreeBSD lines, because they're sufficiently different from the ones above. |
Hi Renato:
I have made changes as suggested (unless I got somethings wrong).
- Now, except for android, AAPCS => 64-bit alignment
- The fix relies only on the triple for I am not sure if 'right cc1' flag test is needed.
- Added gnueabi and FreeBSD as suggested.
Please have a look. Thanks.
--Javed
@srhines: Do you need Android to *always* be 64-bit, even if someone forces aapcs with it?
128-bit always. We don't support "multiple" ABIs. There is only one, and it makes sense to not allow people to choose something that can't work.
Can you make sure that an Android triple doesn't trigger this? I worry because I am not sure what getABI() will return in that case.