On Wed, 20 Jun 2012, Richard Guenther wrote: > On Wed, 20 Jun 2012, Iain Sandoe wrote: > > > Hi, > > > > On 20 Jun 2012, at 09:23, Richard Guenther wrote: > > > > > On Tue, 19 Jun 2012, Iain Sandoe wrote: > > > > > >> > > >> On 19 Jun 2012, at 22:41, Mike Stump wrote: > > >> > > >>> On Jun 19, 2012, at 12:22 PM, Iain Sandoe <i...@codesourcery.com> wrote: > > >>>> On 19 Jun 2012, at 13:53, Dominique Dhumieres wrote: > > >>>> > > >>>>> On Tue, 19 Jun 2012, Richard Guenther wrote: > > >>>>>> > > >>>>>>> Richard Guenther <rguent...@suse.de> writes: > > >>>>>>>> We are too eager to bump alignment of some decls when vectorizing. > > >>>>>>>> The fix is to not bump alignment of decls the user explicitely > > >>>>>>>> aligned or that are used in an unknown way. > > >>>>>>> > > >>>>>>> I thought attribute((__aligned__)) only set a minimum alignment for > > >>>>>>> variables? Most usees I've seen have been trying to get better > > >>>>>>> performance from higher alignment, so it might not go down well if > > >>>>>>> the > > >>>>>>> attribute stopped the vectoriser from increasing the alignment still > > >>>>>>> further. > > >>>>>> > > >>>>>> That's what the documentation says indeed. I'm not sure which part > > >>>>>> of > > >>>>>> the patch fixes the ObjC failures where the alignment is part of the > > >>>>>> ABI > > >>>>>> (and I suppose ObjC then mis-uses the aligned attribute?). > > >>>>> > > >>>>> A quick test shows that > > >>>>> > > >>>>> if (DECL_PRESERVE_P (decl)) > > >>>>> > > >>>>> alone is enough to fix the objc failures, while they are still there > > >>>>> if > > >>>>> one uses only > > >>>>> > > >>>>> if (DECL_USER_ALIGN (decl)) > > >>>> > > >>>> That makes sense, I had a quick look at the ObjC code, and it appears > > >>>> that the explicit ALIGNs were never committed to trunk. > > >>>> > > >>>> Thus, the question becomes; what should ObjC (or any other) FE do to > > >>>> ensure that specific ABI (upper) alignment constraints are met? > > >>> > > >>> Hum, upper is easy... I thought the issue was that extra alignment > > >>> would kill it? I know that extra alignment does kill some of the objc > > >>> metadata. > > >> > > >> clearly, ambiguous phrasing on my part. > > >> I mean when we want to say "no more than this much". > > > > > > I think the only way would be to lay out things inside a structure. > > > > > > > Otherwise if extra alignment can break things cannot re-ordering of > > > symbols break, too? Or can you elaborate on how extra alignment > > > breaks stuff here? > > > > The NeXT runtime meta-data are anonymous and stored in named sections; > > The names of the sections are known to the runtime, which looks up the data > > directly. > > > > In the case that's failing we have class references (which are, > > effectively, pointers to strings). > > The (m32, v0 or v1) runtime knows that the number of names is the section > > size / sizeof(long). > > > > Bumping up the alignment of these items makes it look like there are more > > name pointers present. > > > > For later versions of (Darwin) ld, this is caught by the linker; for > > earlier versions the exe will fail. > > > > The order of the names or other items is not significant (or has already > > been handled by the runtime). > > > > [It might be possible rejig the class ref. list as an array, or a structure > > containing only longs, but I'll need to look at that later]. > > > > However, it seems reasonable that ABIs could require both upper and lower > > limits on alignment; > > are we saying that the only way to handle the 'upper' is by declaring > > things 'packed' and putting them into a crafted structure? > > Yes, I think so. It would also be reasonable to have > __attribute__((aligned(8),packed)) specify that's a hard alignment > requirement, not a lower bound. Not sure if that works to that effect > though. At least > > int c __attribute__((aligned(8),packed)); > > tells you that the packed attribute is ignored. > > If you pack things inside an array the array itself might still get > larger alignment (though of course not its elements). So if you > rely on section concatenation not producing gaps even the > packed structure may not be a good solution - it's start address > can still get a bigger alignment. > > So I think there does not exist a way to tell GCC that the start > address of an object ought not to be aligned in another way > than the ABI specifies (though the ABIs I know only specify > minimum alignments, not maximum ones ...).
>From reading your description of the issue again I think that an array of names is what you want. Richard.
