This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: alignment: store_one_arg vs emit_push_insn
> MAX is correct in this case because we know that we're storing
> to a parameter, and we know that PARM_BOUNDARY is the minimum
> alignment of any parameter.
The problem is that the alignment is used to choose a move_by_pieces
mode, and HImode is chosen, and the object we're copying *from* is not
HI-aligned.
There are two alignments, the alignment of the object on the stack,
and the alignment of the object we're copying from. parm_align is
computed as if it were the stack alignment, but used as if it were the
"from" alignment also.
> > The way the code is now, xstormy16 is trying to access
> > a byte-aligned object with a HImode move, and failing
>
> You don't give enough information to determine why this might
> be the case.
parm_align is used here:
emit_push_insn (arg->value, arg->mode, TREE_TYPE (pval), size_rtx,
parm_align, partial, reg, excess, argblock,
ARGS_SIZE_RTX (arg->locate.offset), reg_parm_stack_space,
ARGS_SIZE_RTX (arg->locate.alignment_pad));
The comments in front of emit_push_insn state:
ALIGN (in bits) is maximum alignment we can assume.
and later used here:
move_by_pieces (NULL, xinner, INTVAL (size) - used, align);
In the xstormy16 case, parm_align is 16 (the stack is HI-aligned), but
the array we're pushing on the stack is QI-aligned (the tree for it
has align=8). But we end up passing "16" to move_by_pieces, which is
wrong.
It looks like emit_push_insn does *not* want the alignment on the
stack, or at least needs both the desired final alignment *and* the
worst-case alignment. Or at least emit_push_insn needs to check the
alignment of the type tree passed to it, and do the right thing wrt
move_by_pieces.