Re: alignment: store_one_arg vs emit_push_insn

[DJ Delorie <dj@redhat.com>]

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