[LLVMdev] ARM struct byval size > 64 triggers failure

[Renato Golin]

Hi Rajesh,

Stepan and Manman were changing that part of the code recently, so they can
have better answer than I do.


On 18 June 2013 12:26, Rajesh Viswabramana <rajesh.vis at samsung.com> wrote:

>  *Output on arm :*
>
> # ./check114.exe
> values 0x10861, 0x4071706f
> which is wrong.
>

This works on my Chromebook, is this soft-float? Can you show us your
compilation options and to which target you're compiling to, please?



> When the offset(#76) for the instruction, "ldr r1, [r11, #76] ; 0x4c"
> is calculated, 4 bytes alignment is considered.
> In prologue stackpointer calculation 8 byte alignment is considered.
>
> Due to this mimatch of alignment, If try to access any parameter after
> byval which results wrong value.
>
> Issue(or offset of 4 bytes) wont occur if even number of register used for
> byval spilling.
> ex:
> struct S114 check114 (int a, struct S114 arg0, struct S114* arg1) { //
> accessing arg1 is fine in this case
> .....
> }
>
This looks like a bug. ;)



> 1) Is this 8 byte alignment mandatory ?  Is this due to " ARM AAPCS
> 5.2.1.2 Stack constraints at a public interface" ? Can this be removed?
>
I'm not sure what you want removed here. AAPCS should be followed to
guarantee compatibility. It looks to me as though the code is considering
different constraints in different places, and all we need to do is to
match the logic on both places.


2) We will leave alignment as it is but in prologue we will adjust SP once
> again, this is little meaningless.
>
> 3) While accessing arg1 we will consider alignment and add extra offset ->
> looks better.
>
I think both are bad fixes, as they don't fix the correct problem. Once the
bug is fixed on trunk, can you use trunk LLVM? Or do you have to use a
point-version?

Anyway, changing your code to work around compiler issues is always a bad
idea...


 Offset to access arg1 is calculated by selection DAG that will be target
> independent. But Alignment adjustment should be done by target lowering.
> Any suggestions on how to fix this ?
>
I'm not too familiar with that part of the code, but Manman or Stepan can
give you a hand here.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130618/a9d4ba0d/attachment.html>