Andrew Lenharth
2010-Jul-14 15:57 UTC
[LLVMdev] different layout of structs for llc vs. llvm-gcc
On Wed, Jul 14, 2010 at 10:54 AM, Eli Friedman <eli.friedman at gmail.com> wrote:> On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: >> 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? > > Irrelevant here; the struct in question only has 4 byte alignment.Not meant to be irrelevant because the though not explained. What I meant to say was if the padding was accomplished with an align directive on the field, would the alignment be propagated to the global after being split up? Andrew> > -Eli >
Torvald Riegel
2010-Jul-14 21:03 UTC
[LLVMdev] different layout of structs for llc vs. llvm-gcc
On Wednesday 14 July 2010 17:57:26 Andrew Lenharth wrote:> On Wed, Jul 14, 2010 at 10:54 AM, Eli Friedman <eli.friedman at gmail.com>wrote:> > On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org>wrote:> >> On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com>wrote:> >> Is alignment on a field propagated when the struct is split up? > > > > Irrelevant here; the struct in question only has 4 byte alignment. > > Not meant to be irrelevant because the though not explained. What I > meant to say was if the padding was accomplished with an align > directive on the field, would the alignment be propagated to the > global after being split up?I tried this already (in the form of { uint32_t field; uint8_t pad[60]; uint32_field2;}). Alignment seems to be properly propagated, but pad[] is still removed, so I believe that other globals without custom alignment constraints could still be located in the same cachelines as field or field2. Torvald
Reid Kleckner
2010-Jul-14 21:17 UTC
[LLVMdev] different layout of structs for llc vs. llvm-gcc
I believe he was asking if adding __attribute__((aligned(NN))) to the fields worked. It's probably a cleaner away of accomplishing alignment than padding. Reid On Wed, Jul 14, 2010 at 2:03 PM, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote:> On Wednesday 14 July 2010 17:57:26 Andrew Lenharth wrote: >> On Wed, Jul 14, 2010 at 10:54 AM, Eli Friedman <eli.friedman at gmail.com> > wrote: >> > On Wed, Jul 14, 2010 at 8:33 AM, Andrew Lenharth <andrewl at lenharth.org> > wrote: >> >> On Wed, Jul 14, 2010 at 10:26 AM, Eli Friedman <eli.friedman at gmail.com> > wrote: >> >> Is alignment on a field propagated when the struct is split up? >> > >> > Irrelevant here; the struct in question only has 4 byte alignment. >> >> Not meant to be irrelevant because the though not explained. What I >> meant to say was if the padding was accomplished with an align >> directive on the field, would the alignment be propagated to the >> global after being split up? > > I tried this already (in the form of { uint32_t field; uint8_t pad[60]; > uint32_field2;}). Alignment seems to be properly propagated, but pad[] is still > removed, so I believe that other globals without custom alignment constraints > could still be located in the same cachelines as field or field2. > > Torvald > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
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