RFC (proposed fix for PR18916)

[Fariborz Jahanian <fjahanian at apple dot com>]

PR18916

Several dejagnu tests in powerpc's mixed mode (-mcpu=G5) fail due to a 
recent
addition in powerpc's back-end to use vector moves when alignment is 
perceived to
be 128 bits. Problem is that event though the alignment in rtl for 
source and destination
are set to 128, but the memory addresses don't end up to be 128bit 
aligned. AltiVec
instructions cause vector move for the 128bit aligned address anyhow,
causing incorrect behavior. Problem is only when vector temporaries are 
allocated on stack. User
declared local vector variables are aligned correctly on the stack. My 
first attempt was to
produce correct alignment in all cases, but this broke ABI 
compatibility. So, I concluded that the
safest fix (short of removing the code which does the vector move) 
would be to set the alignment
of the rtl generated for the stack temporaries to their default stack 
alignment. Attached  patch
demonstrates what I have in mind. It passes all the failed test by 
preventing illegal vector copying
from taking place. Of course this patch is not FSF-ready, but is just 
to illustrate the approach.
Comments are appreciated, specially from maintainer of other platforms 
with similar issues.


- Thanks, fariborz (fjahanian@apple.com).

Index: expr.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.761
diff -c -p -r1.761 expr.c
*** expr.c      18 Dec 2004 14:38:31 -0000      1.761
--- expr.c      23 Dec 2004 18:35:06 -0000
*************** emit_push_insn (rtx x, enum machine_mode
*** 3457,3463 ****
             to record the alignment of the stack slot.  */
          /* ALIGN may well be better aligned than TYPE, e.g. due to
             PARM_BOUNDARY.  Assume the caller isn't lying.  */
!         set_mem_align (target, align);

          emit_block_move (target, xinner, size, BLOCK_OP_CALL_PARM);
        }
--- 3457,3469 ----
             to record the alignment of the stack slot.  */
          /* ALIGN may well be better aligned than TYPE, e.g. due to
             PARM_BOUNDARY.  Assume the caller isn't lying.  */
!           /* powerpc-darwin currently does not enforce 128 bit 
alignment of
!              temporaries on the stack. To do so, requires changes 
which will break
!              ABI compatibility. On the other hand, Leaving this 
unchanged generates
!              incorrect code in cases where block move is implemented 
using
!              AltiVec instructions whose src and dest must be 128 bit 
aligned
!              (expand_block_move implementation in rs6000.c). */
!           set_mem_align (target, align >= 128 ? PARM_BOUNDARY : 
align);

          emit_block_move (target, xinner, size, BLOCK_OP_CALL_PARM);
        }
*************** store_expr (tree exp, rtx target, int ca
*** 4206,4214 ****
        emit_group_load (target, temp, TREE_TYPE (exp),
                         int_size_in_bytes (TREE_TYPE (exp)));
        else if (GET_MODE (temp) == BLKmode)
!       emit_block_move (target, temp, expr_size (exp),
!                        (call_param_p
!                         ? BLOCK_OP_CALL_PARM : BLOCK_OP_NORMAL));
        else
        {
          temp = force_operand (temp, target);
--- 4212,4228 ----
        emit_group_load (target, temp, TREE_TYPE (exp),
                         int_size_in_bytes (TREE_TYPE (exp)));
        else if (GET_MODE (temp) == BLKmode)
!         {
!         if (!DECL_P (exp))
!           {
!             /* See previous comment. */
!             int align = MEM_ALIGN (temp);
!             set_mem_align (temp, align >= 128 ? PARM_BOUNDARY : 
align);
!           }
!           emit_block_move (target, temp, expr_size (exp),
!                            (call_param_p
!                             ? BLOCK_OP_CALL_PARM : BLOCK_OP_NORMAL));
!         }
        else
        {
          temp = force_operand (temp, target);