Torvald Riegel
2010-Jul-14 10:20 UTC
[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
Eli Friedman
2010-Jul-14 15:26 UTC
[LLVMdev] different layout of structs for llc vs. llvm-gcc
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
Andrew Lenharth
2010-Jul-14 15:33 UTC
[LLVMdev] different layout of structs for llc vs. llvm-gcc
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
Eli Friedman
2010-Jul-14 15:53 UTC
[LLVMdev] different layout of structs for llc vs. llvm-gcc
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
Maybe Matching Threads
- [LLVMdev] different layout of structs for llc vs. llvm-gcc
- [LLVMdev] different layout of structs for llc vs. llvm-gcc
- [LLVMdev] different layout of structs for llc vs. llvm-gcc
- [LLVMdev] different layout of structs for llc vs. llvm-gcc
- [LLVMdev] different layout of structs for llc vs. llvm-gcc