llvm dev - May 2015 - [LLVMdev] question about alignment of structures on the stack (arm 32)

----------------------------------------
> Date: Thu, 23 Apr 2015 09:33:58 -0700
> Subject: Re: [LLVMdev] question about alignment of structures on the stack
(arm 32)
> From: t.p.northover at gmail.com
> To: alexey.perevalov at hotmail.com
> CC: llvmdev at cs.uiuc.edu; lubos at dolezel.info
>
>>> void func(int x, long long y)
>>>
>>> iOS will pass y in registers r1 and r2. ELF code will expect it in
>>> registers r2 and r3. Similar effects happen to arguments that get
>>> passed on the stack.
>> Strange, but in that simple case on ELF I got,
>> mov r0, #1
>> mov r1, #18
>> mov r2, #0
>> bl long_long_func
>> with the same endian as on iOS,
>
> That almost certainly means you're using the wrong triple on Linux
> (and so would have problems calling system library functions with that
> signature). Most ARM linux distributions these days use
> arm-linux-gnueabihf (or possibly arm-linux-gnueabi, the difference
> being where floating-point arguments get passed).
>
You totally right.
> If that's changed in your upgrade to 3.6, it might account for you
> seeing "add" instead of "orr" now, too.
>
>>> I wouldn't rely on this. Trunk emits orr again, it's likely
just a
>>> random code perturbation and will bite you elsewhere without a real
>>> solution.
>>>
>> Trunk of llvm's source code ) ?
>
> Yes.
>
> Tim.

Hello Tim,

I have one more question regarding call convention

for example cmd line is following:
clang -target arm-apple-darwin10 -mabi=apcs-gnu -fPIC -o main_36.llvm main.c -O1
-mfloat-abi=soft -emit-llvm

(I'm using clang from https://github.com/llvm-mirror/clang branch master, on
top of "clang-format: Fix for #pragma option formatting." commit
in llvm tree https://github.com/llvm-mirror/llvm.git branch master on top of
"[AArch64] Disable complex GEP optimization by default" commit,
I'm not svn user :-) )
for function
void main_long_long_func(int a, long long b)
__attribute__((pcs("aapcs"))) ;

I could see
define i32 @main(i32 %argc, i8** nocapture readnone %argv) #2 {
entry:
  tail call arm_aapcscc void @main_long_long_func(i32 1, i64 19)
And it's expected, whole file in apcs-gnu, but only main_long_long_func is
in AAPCS.
But when I produce just assembly code,
clang -target arm-apple-darwin10 -mabi=apcs-gnu -fPIC -o main_36.s main.c -O1
-mfloat-abi=soft -S
or without -mabi=apcs-gnu
I got call
        mov     r0, #1
        mov     r1, #19
        mov     r2, #0
        bl      _main_long_long_func
in APCS convention, but not AAPCS, and function itself expects second argument
in r1, r2.
Maybe I misunderstood, but I thought that attribute is changing calling
convention?
The same situation if main_long_long_func is in file with was compiled with
-target armv7l-linux-gnueabi,
attribute doesn't change call convention at the invocation point. 

----------------------------------------
> From: alexey.perevalov at hotmail.com
> To: t.p.northover at gmail.com
> Date: Fri, 24 Apr 2015 11:53:10 +0300
> CC: lubos at dolezel.info; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] question about alignment of structures on the stack
(arm 32)
>
>
>
> ----------------------------------------
>> Date: Thu, 23 Apr 2015 09:33:58 -0700
>> Subject: Re: [LLVMdev] question about alignment of structures on the
stack (arm 32)
>> From: t.p.northover at gmail.com
>> To: alexey.perevalov at hotmail.com
>> CC: llvmdev at cs.uiuc.edu; lubos at dolezel.info
>>
>>>> void func(int x, long long y)
>>>>
>>>> iOS will pass y in registers r1 and r2. ELF code will expect it
in
>>>> registers r2 and r3. Similar effects happen to arguments that
get
>>>> passed on the stack.
>>> Strange, but in that simple case on ELF I got,
>>> mov r0, #1
>>> mov r1, #18
>>> mov r2, #0
>>> bl long_long_func
>>> with the same endian as on iOS,
>>
>> That almost certainly means you're using the wrong triple on Linux
>> (and so would have problems calling system library functions with that
>> signature). Most ARM linux distributions these days use
>> arm-linux-gnueabihf (or possibly arm-linux-gnueabi, the difference
>> being where floating-point arguments get passed).
>>
> You totally right.
>
>> If that's changed in your upgrade to 3.6, it might account for you
>> seeing "add" instead of "orr" now, too.
>>
>>>> I wouldn't rely on this. Trunk emits orr again, it's
likely just a
>>>> random code perturbation and will bite you elsewhere without a
real
>>>> solution.
>>>>
>>> Trunk of llvm's source code ) ?
>>
>> Yes.
>>
>> Tim.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On 1 May 2015 at 01:55, Alexey Perevalov <alexey.perevalov at hotmail.com>
wrote:
> clang -target arm-apple-darwin10 -mabi=apcs-gnu -fPIC -o main_36.llvm
main.c -O1 -mfloat-abi=soft -emit-llvm
The most reliable way to emit ARM code that's compatible with iOS is
probably:
    clang -target x86_64-apple-macosx10.10 -arch armv7s ...

With that you certainly won't need to override the float-abi or abi.
I've been meaning to get "thumbv7s-apple-ios8.0" or whatever
working
for a while too, but at the moment you need to specify x86 and then
"-arch" to set the real target for best results.
> in APCS convention, but not AAPCS, and function itself expects second
argument in r1, r2.
Unfortunately, it looks like attribute((pcs("aapcs"))) doesn't
work
when the general compilation environment is APCS. The immediate reason
is that it looks for the 64-bit alignment of the i64 to decide whether
to leave a hole (see ARMCallingConv.td:124), but i64 is only 32-bit
aligned in APCS. This particular issue could be fixed.

At a higher level though, it was designed as an attribute to interwork
between hard and soft-float versions of otherwise compatible ABIs.
There's no way it could reliably work on APCS (e.g. what do you do
when passing "struct { int a; long long b; }", where the layouts are
different on either side).

Cheers.

Tim.