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 ...). Richard.
