llvm dev - Jul 2010 - [LLVMdev] different layout of structs for llc vs. llvm-gcc

Hi,

attached is small program in which padding inside a struct is lost when using 
llc, but is not lost when using llvm-gcc or gcc. In particular, padding is 
missing after codegen with llc (see (1) below, LLVM 2.7, Linux x86_64):
typedef struct {
    unsigned txnal;
    char padding[64];
    unsigned nontxnal;
} Data;
Data data;

I thought that the layout of structs was supposed to be preserved (wrong 
assumption?). Otherwise, any ideas why this happens?

Thanks,
Torvald

(1)
llvm-gcc -emit-llvm -c -o padtest.bc padtest.c; llvm-ld -link-as-library 
padtest.bc -o padtest2.bc; llc padtest2.bc -o padtest.s; gcc padtest.s  -
lpthread -o padtestllc

0000000000400640 <updater>:
  400640:       89 3d 9a 04 20 00       mov    %edi,0x20049a(%rip)        # 
600ae0 <data.0>
  400646:       89 3d 98 04 20 00       mov    %edi,0x200498(%rip)        # 
600ae4 <data.2>

padtest2.bc (input to llc) still has the padding in the struct. Also note that 
the padding is not removed if the addresses of data's fields are printed.


(2)
llvm-gcc padtest.c -o padtesto3 -O3 -lpthread

00000000004005d0 <updater>:
  4005d0:       89 3d ea 04 20 00       mov    %edi,0x2004ea(%rip)        # 
600ac0 <data>
  4005d6:       89 3d 28 05 20 00       mov    %edi,0x200528(%rip)        # 
600b04 <data+0x44>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: padtest.c
Type: text/x-csrc
Size: 947 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100713/ca643219/attachment.c>

On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel
<torvald at se.inf.tu-dresden.de> wrote:
> Hi,
>
> attached is small program in which padding inside a struct is lost when
using
> llc, but is not lost when using llvm-gcc or gcc. In particular, padding is
> missing after codegen with llc (see (1) below, LLVM 2.7, Linux x86_64):
> typedef struct {
>    unsigned txnal;
>    char padding[64];
>    unsigned nontxnal;
> } Data;
> Data data;
>
> I thought that the layout of structs was supposed to be preserved (wrong
> assumption?). Otherwise, any ideas why this happens?
It should be preserved in general; probably what's happening here is
that when you use llvm-ld, it assumes the variable data isn't used
outside of the file in question.  Therefore, it ends up splitting the
global into its respective members and eliminating the apparently
unused padding.  Passing -disable-internalize to llvm-ld or declaring
data as volatile should solve this.

-Eli

On Tuesday 13 July 2010 19:48:25 you wrote:
> On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel
> > I thought that the layout of structs was supposed to be preserved
(wrong
> > assumption?). Otherwise, any ideas why this happens?
> 
> It should be preserved in general;
Is this a "should" or a "must"? Are there any cases in which
structure layout
must be preserved besides for volatile accesses and if the data goes out to 
external code?

I've seen code like the one above quite often to put data on different 
cachelines, so even if it's a "should" and not a "must"
it might be good to
preserve the padding. Otherwise, is there a portable way to ensure that 
globals end up on a separate cacheline (without making all accesses to them 
volatile)?
> probably what's happening here is
> that when you use llvm-ld, it assumes the variable data isn't used
> outside of the file in question.  Therefore, it ends up splitting the
> global into its respective members and eliminating the apparently
> unused padding.  Passing -disable-internalize to llvm-ld or declaring
> data as volatile should solve this.
-disable-internalize helps, as does making either of the two accessed fields 
volatile (making the padding volatile doesn't). However, I don't want
them to
be volatile. A single volatile initializing access to the first field seems to 
keep the structure layout, interestingly.

Torvald