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

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

On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel
<torvald at se.inf.tu-dresden.de> wrote:
> 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?
LLVM generally doesn't attempt to preserve the layout of structs which
aren't externally visible or used by a volatile load/store.
> 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)?
I can't think of any way of doing it without essentially trying to
trick the compiler... although there are many ways to trick LLVM.

Anyone else have ideas?

-Eli

On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com>
wrote:
> On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel
> <torvald at se.inf.tu-dresden.de> wrote:
>> 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?
>
> LLVM generally doesn't attempt to preserve the layout of structs which
> aren't externally visible or used by a volatile load/store.
>
>> 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)?
>
> I can't think of any way of doing it without essentially trying to
> trick the compiler... although there are many ways to trick LLVM.
>
> Anyone else have ideas?
Is alignment on a field propagated when the struct is split up?

Andrew

On Wed, Jul 14, 2010 at 8:26 AM, Eli Friedman <eli.friedman at gmail.com>
wrote:
> On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel
> <torvald at se.inf.tu-dresden.de> wrote:
>> 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?
>
> LLVM generally doesn't attempt to preserve the layout of structs which
> aren't externally visible or used by a volatile load/store.
>
>> 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)?
>
> I can't think of any way of doing it without essentially trying to
> trick the compiler... although there are many ways to trick LLVM.
>
> Anyone else have ideas?
Oh, something I forgot earlier: the generic "don't touch this
global"
directive is "__attribute__((__used__))".

-Eli