[cfe-commits] [PATCH] AArch64 backend: Clang changes

John McCall rjmccall at apple.com
Tue Jan 15 10:57:02 PST 2013


On Jan 14, 2013, at 5:21 AM, Tim Northover <t.p.northover at gmail.com> wrote:
>> It seems to be the case that aarch64's ABI is just the ARM32 ABI except
>> that ABI guards are 64-bit.  A cleaner way of expressing this would be to
>> say that aarch64 uses the ARM ABI, and that the ARM ABI says that ABI
>> guards are size_t's.  Are you expecting further divergences?
> 
> It would be a simpler change and we're certainly not anticipating any
> more differences on the AArch64 side. This was actually an attempt to
> improve existing code; I didn't like "IsARM" covering multiple
> different company-specific traits that other targets might want to
> change.

I agree that the IsARM bit is ugly, but I prefer not to increase abstraction
without a real understanding of what the expected variation is going to be.

It would be better to use methods instead of extra bools, anyway.

>> Can I kibbitz about your ABI here, or is it too late and you've actually
>> committed to it?
> 
> I'm afraid it is too late for changes now, barring complete breakage
> being discovered. The specification is published and implemented by at
> least two separate compilers (GCC and ARMCC).

Okay, just idly curious.

>> I will note that your va_arg code is *huge*.
> 
> It's a similar size to the x86_64 code. I suspect the complexity is
> inevitable to manage the possibility of arguments going in either
> general registers, floating registers or on the stack independently.

> 
> AAPCS gets around it by requiring soft-float for variadic functions so
> that a single pointer suffices in va_list.

Yeah, in principle it's obviously best to always pass variadic arguments
on the stack.  I can sympathize with ABI authors who are afraid of
the K&R legacy, though.

John.



More information about the cfe-commits mailing list