[Bug rtl-optimization/95493] [10/11 Regression] test for vector members apparently reordered with assignment to vector members since r10-7523-gb90061c6ec090c6b

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95493

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |rtl-optimization

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
>   VIEW_CONVERT_EXPR<int[4]>(MEM[(struct SW &)&xx].d)[i.1_2] = -1;
>   _4 = MEM[(struct SW &)&xx].d;
>   y = _4;
> 
> There is some aliasing issues with the store and the next load.
> 
> THe tree level is correct, it goes wrong on the RTL level.

;; VIEW_CONVERT_EXPR<int[4]>(MEM[(struct SW &)&xx].d)[i.1_2] = -1;

(insn 28 27 29 (set (reg:DI 92)
        (sign_extend:DI (reg:SI 83 [ i.1_2 ]))) "t.C":50:16 -1
     (nil))

(insn 29 28 0 (set (mem/j:SI (plus:DI (plus:DI (mult:DI (reg:DI 92)
                        (const_int 4 [0x4]))
                    (reg/f:DI 77 virtual-stack-vars))
                (const_int -32 [0xffffffffffffffe0])) [1 MEM[(struct ._anon_0
*)_42] S4 A32])
        (const_int -1 [0xffffffffffffffff])) "t.C":50:16 -1
     (nil))

;; y = _5;

(insn 30 29 31 (set (reg:V4SI 93)
        (mem/c:V4SI (plus:DI (reg/f:DI 77 virtual-stack-vars)
                (const_int -32 [0xffffffffffffffe0])) [1 MEM[(struct SW
&)_42].d+0 S16 A128])) -1
     (nil))

(insn 31 30 0 (set (mem/c:V4SI (plus:DI (reg/f:DI 77 virtual-stack-vars)
                (const_int -16 [0xfffffffffffffff0])) [1 MEM[(vector(4) int
*)_69]+0 S16 A128])
        (reg:V4SI 93)) -1
     (nil))

alias-sets look OK, the bases look sane as well.  The only odd thing
is that (anon *) which might confuse path-based analysis.

PRE indeed decides that insn 29 does not affect the load in insn 30:

deleting insn with uid = 30.
PRE: redundant insn 30 (expression 3) in bb 4, reaching reg is 110
scanning new insn with uid = 146. 
deleting insn with uid = 34.
PRE: redundant insn 34 (expression 1) in bb 5, reaching reg is 111
PRE: edge (13,4), copy expression 1
PRE: edge (13,4), copy expression 3
PRE:  store updated with reaching reg (reg:V4SI 110 [ MEM[(struct SW &)_42].d
]): 
        (insn 109 108 110 13 (set (mem/c:V4SI (plus:DI (reg/f:DI 19 frame)
                                (const_int -32 [0xffffffffffffffe0])) [1
MEM[(struct SW *)_42].d+0 S16 A128])
                        (reg:V4SI 103)) "t.C":47:7 1347 {movv4si_internal}
                     (expr_list:REG_DEAD (reg:V4SI 103)
                        (nil)))


> (In reply to Martin Liška from comment #1)
> > Confirmed, started with r10-7523-gb90061c6ec090c6b.
> 
> No just exposed.