[Bug tree-optimization/101925] [10/11/12 Regression] reversed storage order when compiling with -O3 only since r10-4742-g9b75f56d4b7951c6

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 16 Aug 2021, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101925
> 
> --- Comment #7 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > Disabling SRA fixes it also, and I think that SRA drops the rev storage order
> > access attribute.  Oddly enough for be_ip6_addr I see the rc.u.addr8[]
> > accesses do _not_ result in reverse_storage_order_for_component_p being true.
> > Why's that so?  How should I detect this is subject to re-ordering?
> 
> Because semantically this does not change anything, but I agree that the flag
> should be set in this case too for the sake of the optimizer.  Please remove
> the test on QImode on line 8844 in c/c-decl.c.

OK, so that fixes it with the vectorizer patch.  But then I have no
idea why it breaks in the first place.  With -fdbg-cnt=4:4 (the
only "single" vect case that breaks) I see

   <bb 2> [local count: 1073741824]:
   ip$is_v4_20 = ip.is_v4;
-  rc = {};
+  MEM <char[3]> [(struct _be_net_addr *)&rc + 1B] = {};
   if (ip$is_v4_20 != 0)

(huh, guess DSE goes bonkers)

-  _85 = MEM <unsigned int> [(union  *)&ip + 4B];
+  vect_ip6_u_addr8_0_21.88_86 = MEM <const vector(4) char> [(union  *)&ip 
+ 4B];
...

-  MEM <unsigned int> [(union  *)&rc + 4B] = _85;
-  rc$u$addr_41 ={rev} MEM <int32_t> [(union  *)&rc + 4B];
+  _39 = VIEW_CONVERT_EXPR<int>(vect_ip6_u_addr8_0_21.88_86);

looks like bogus FRE here.

So both not really vectorization but followup opt issues.  
-fdisable-tree-fre5 makes the testcase work.  We're copying
REF_REVERSE_STORAGE_ORDER in copy_reference_ops_from_ref but
vn_reference_eq doesn't compare .reverse, it only has some
early complete out on V_C_E with reverse (aka storage order
barriers - whatever those exactly are).  Also vn_reference_lookup_3
uses contains_storage_order_barrier_p in two places but that
again only checks for the V_C_E barrier, not for reverse accesses.

So we're running into

  /* 4) Assignment from an SSA name which definition we may be able
     to access pieces from or we can combine to a larger entity.  */
  else if (known_eq (ref->size, maxsize)
           && is_gimple_reg_type (vr->type)
           && !contains_storage_order_barrier_p (vr->operands)
           && gimple_assign_single_p (def_stmt)
           && TREE_CODE (gimple_assign_rhs1 (def_stmt)) == SSA_NAME)
    {
...
      reverse = reverse_storage_order_for_component_p (lhs);
      tree def_rhs = gimple_assign_rhs1 (def_stmt);
      if (!reverse
          && !storage_order_barrier_p (lhs)
          && known_size_p (maxsize2)
          && known_eq (maxsize2, size2)
          && adjust_offsets_for_equal_base_address (base, &offset,
                                                    base2, &offset2))
        {

since LHS is

MEM <vector(4) char> [(union  *)&rc + 4B] = vect_ip6_u_addr8_0_21.88_86;

that doesn't trigger anything.  But the ref we're looking at (vr) is
from

rc$u$addr_41 ={rev} MEM <int32_t> [(union  *)&rc + 4B];

but we don't check that for reverse_storage_order_for_component_p.
We do have check contains_storage_order_barrier_p which easily(?)
could at least look for other .reverse == 1 compontents but
reverse_storage_order_for_component_p is a bit more complicated
due to how it handles array and component refs based on their
aggregate base TYPE_REVERSE_STORAGE_ORDER.  I suppose we could
set .reverse for those in copy_reference_ops_from_ref as well.

That fixes it.