This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR target/18916; Function arg passing mem align fixes.


On Sat, Jan 08, 2005 at 01:55:51PM -0800, Richard Henderson wrote:
> On Sat, Jan 08, 2005 at 10:00:04AM +1030, Alan Modra wrote:
> > I chose to put PARM_NEEDS_ALIGN in rs6000.h so that this change would
> > mainly affect powerpc, as I'm not that familiar with other ABIs.  If
> > you think it suitable for all targets I'm quite happy to put the change
> > directly in a_p_adjust_stack_rtl.
> 
> I think that it's definitely suitable for all targets.  More or less
> by definition -- it's exactly the condition that we're providing.

Good.

> > +      stack_parm = assign_stack_local (BLKmode, size_stored, 0);
> 
> Don't you know the alignment that you require?

Yes.  TYPE_ALIGN (data->passed_type), I suppose.  This was existing
code.

> I believe that you need similar changes to assign_parm_setup_stack.
> You probably won't be able to show an Altivec failure, but if you
> examine the MEM_ALIGN data in the rtl dumps, you should see that it's
> insufficient.  Passing a single _Complex long double argument, and
> taking its address, should be sufficient to view the problem.
> Basically, emit_move_insn will only look at the mode and won't
> invoke expand_block_move when needed.

Shouldn't emit_move_insn handle mis-aligned moves anyway?  At least
rs6000_emit_move has code to split DImode moves to SImode depending on
alignment.

A little test like the following reveals emit_move_insn being called
on the misaligned mem for x, so why do anything special for parms if
other parts of the compiler leave the backend emit_move to handle
misalignment?

int x __attribute__ ((aligned (1)));

void foo (void)
{
  x = 1;
}

#0  rs6000_emit_move (dest=0x80002e49d8, source=0x8000204410, mode=SImode)
    at /src/gcc-current/gcc/config/rs6000/rs6000.c:4311
#1  0x0000000010299444 in gen_movsi (operand0=0x80002e49d8, 
    operand1=0x8000204410) at insn-emit.c:11815
#2  0x00000000101fa138 in emit_move_insn_1 (x=0x80002e49d8, y=0x8000204410)
    at /src/gcc-current/gcc/expr.c:3043
#3  0x00000000101fa9fc in emit_move_insn (x=0x80002e49d8, y=Variable "y" is not available.
)
    at /src/gcc-current/gcc/expr.c:3121
#4  0x00000000101fff08 in store_expr (exp=0x8000220570, target=0x80002e49d8, 
    call_param_p=0) at /src/gcc-current/gcc/expr.c:4264
#5  0x0000000010201a48 in expand_assignment (to=0x80002ee680, from=0x0)
    at /src/gcc-current/gcc/expr.c:3986
#6  0x00000000101f1340 in expand_expr_real_1 (exp=0x8000205678, 
    target=0x8000204400, tmode=VOIDmode, modifier=Variable "modifier" is not available.
)
    at /src/gcc-current/gcc/expr.c:8068
#7  0x00000000101f9b10 in expand_expr_real (exp=0x8000205678, 
    target=0x8000204400, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
    at /src/gcc-current/gcc/expr.c:6284
#8  0x000000001037d2e8 in expand_expr_stmt (exp=0x80002e49d8) at expr.h:481
#9  0x00000000103c3b50 in expand_gimple_basic_block (bb=0x80002f90d0, 
    dump_file=Variable "dump_file" is not available.
) at /src/gcc-current/gcc/cfgexpand.c:1133
#10 0x00000000103c49c8 in tree_expand_cfg ()
    at /src/gcc-current/gcc/cfgexpand.c:1306

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]