https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, it seems the .LC0 VAR_DECL that is newly created undergoes
DATA_ABI_ALIGNMENT, DATA_ALIGNMENT and CONSTANT_ALIGNMENT treatment, but the
rs6000 backend doesn't consider it worthwhile to bump the alignment.
Old gimplify used to bump the alignment for the ctors to the alignment of the
var being initialized:
new_tree = create_tmp_var_raw (type, "C");
gimple_add_tmp_var (new_tree);
TREE_STATIC (new_tree) = 1;
TREE_READONLY (new_tree) = 1;
DECL_INITIAL (new_tree) = ctor;
if (align > DECL_ALIGN (new_tree))
{
DECL_ALIGN (new_tree) = align;
DECL_USER_ALIGN (new_tree) = 1;
}
which is definitely very excessive (128-byte alignment is bigger than
MAX_ALIGNMENT and hardly useful here).
I'd say if you think this is worth doing anything at all, then the best choice
might be to increase CONSTANT_ALIGNMENT for initializers larger than say 128
bits to 128 bits if Altivec or VSX is enabled - in current GCCs
CONSTANT_ALIGNMENT should be assumed only for decls that bind to the current
def, so the macro should be a pure optimization thing rather than an ABI thing,
only tweaking CONSTANT_ALIGNMENT would actually affect code that doesn't use
explicit align attribute on the vars.
The other possibility is to pass an extra align argument to
tree_output_constant_def and build_constant_def, that, if non-0, could bump
alignment of the created decl to what the caller would prefer to see.
We certainly should max that to BIGGEST_ALIGNMENT though, and in any case
wouldn't guarantee it, because the constant might have been already found in
the constant pool and at that point it has rtl created and it is too late for
bumping alignment.
