[LLVMdev] question about alignment of structures on the stack (arm 32)

[Alexey Perevalov]

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