http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> 2013-02-14 10:41:07 UTC --- On Thu, 14 Feb 2013, ebotcazou at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 > > --- Comment #17 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2013-02-14 > 09:18:46 UTC --- > > Because as it is seen as a regular VAR_DECL by optimizers the > > vectorizer (well, IPA increase-alignment in this case) chooses to > > bump its alignment to be able to use aligned vector moves. > > > > Thus we need to honor the increased DECL_ALIGN when outputting the > > constant pool, otherwise we generate wrong-code. > > I see, thanks. Perhaps the safest solution is to prevent IPA from increasing > the alignment if DECL_IN_CONSTANT_POOL, as initializations of aggregate > objects > are presumably not supposed to happen in hot spots. It's also done by the vectorizer pass (for -fno-section-anchors). I believe it's wrong to not honor DECL_ALIGN of decl in /* If this variable belongs to the global constant pool, retrieve the pre-computed RTL or recompute it in LTO mode. */ if (TREE_CODE (decl) == VAR_DECL && DECL_IN_CONSTANT_POOL (decl)) { SET_DECL_RTL (decl, output_constant_def (DECL_INITIAL (decl), 1)); return; which is what happens here. Thus, if we say DECL_IN_CONSTANT_POOL decls may not have their alignment changed we should assert that (but my patch just honors DECL_ALIGN and avoids creation of yet another DECL_IN_CONSTANT_POOL decl ...). After all we also use DECL_ALIGN information if anybody inspects the address (which may happen if we elide the local static to the initializer if we can see it is never changed - I suppose we cannot do that at the moment) Btw, if properly aligned the block-move can use vector code as well (not sure if any target does that though). Richard.
