[Bug tree-optimization/55614] [4.6/4.7 Regression] vector extensions cause movdqa to be generated for memcpy on unaligned buffer

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55614

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |tree-optimization
      Known to work|                            |4.5.0, 4.8.0
      Known to fail|                            |4.6.3, 4.7.2

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-07 14:30:22 UTC ---
The difference from broken to working starts at the esra pass:
 <bb 3>:
-  MEM[(char * {ref-all})x_1].v = r$v_15;
+  MEM[(char * {ref-all})x_1] = r$v_15;
   x_8 = x_1 + 16;
   y_9 = y_2 + 18446744073709551600;

Note that the MEM[(char * {ref-all})x_1] is
 <mem_ref 0x7ffff1a93d48
    type <union_type 0x7ffff1a9cb28 sizes-gimplified type_0 TI
        size <integer_cst 0x7ffff1982dc0 constant 128>
        unit size <integer_cst 0x7ffff1982de0 constant 16>
        align 8 symtab 0 alias set -1 canonical type 0x7ffff1a9c738
        fields <field_decl 0x7ffff19a45f0 v type <vector_type 0x7ffff1a9c498 T>
            unsigned V4SI file rh885082.c line 7 col 13 size <integer_cst
0x7ffff1982dc0 128> unit size <integer_cst 0x7ffff1982de0 16>
            align 128 offset_align 128
            offset <integer_cst 0x7ffff1982d80 constant 0>
            bit offset <integer_cst 0x7ffff1982e00 constant 0> context
<union_type 0x7ffff1a9c738>> context <function_decl 0x7ffff1a9ba00 foo>>

    arg 0 <ssa_name 0x7ffff1985bd0
        type <pointer_type 0x7ffff1a9c5e8 type <integer_type 0x7ffff1997348
unsigned char>
            unsigned DI
            size <integer_cst 0x7ffff1982d40 constant 64>
            unit size <integer_cst 0x7ffff1982d60 constant 8>
            align 64 symtab 0 alias set -1 canonical type 0x7ffff1a9c5e8>
        visited var <parm_decl 0x7ffff1ab6000 x>def_stmt x_1 = PHI <x_10(D)(2),
x_13(3)>

        version 1
        ptr-info 0x7ffff1aa48a0>
    arg 1 <integer_cst 0x7ffff1aa63e0 type <pointer_type 0x7ffff1a9ca80>
constant 0>>

thus it has the right TYPE_ALIGN.  But when it is wrapped into COMPONENT_REF,
while the inner MEM_REF still has TYPE_ALIGN 8, the FIELD_REF has DECL_ALIGN
128, which is probably why the expansion expands it as aligned.
If the r186501 patch is too risky for the release branches (did it need any
follow-ups so far?), an alternative would be to start doing what trunk does
only
if the MEM_REF has lower alignment than the field.