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

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

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

--- Comment #5 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-12-07 14:57:28 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>>

How can a union have alignment 8 if it contains a field with alignment 128? 
That should only happen if the field is a bit-field...

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

...in which case the expansion should expand it as a bit-field.

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

I don't think that r186501 can be backported, unless you want to break again
the strict-alignment platforms.  r161958 just fixed the disaster introduced on
them by an ealier patch, see PR middle-end/44843.