[Bug tree-optimization/66142] Loop is not vectorized because not sufficient support for GOMP_SIMD_LANE

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

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

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, so if we fix SCCVN further we hit its (designed) limitation with stmt
walking not following backedges (but the use is in a loop and the def outside).
We avoid doing the work to determine if sth is loop invariant here.
This was trying to improve things with SRA disabled - I'm going to still push
those changes if testing works out fine.

Now with SRA enabled we have a better situation in this regard but face

  _9 = &D.4309[_12].org;
  MEM[(struct vec_ *)_9] = 1.0e+0;
  MEM[(struct vec_ *)_9 + 4B] = _8;
  D.4309[_12].dir.x = x_13;
  D.4309[_12].dir.y = y_14;
  D.4308[_12].t = 1.0e+10;
  D.4308[_12].h = 0;
  _20 = &D.4308[_12];
  _26 = MEM[(const struct Ray *)&D.4309][_12].org.x;

which as said isn't friendly enough for the simplistic address forward
propagation we have.  The issue here is that we can't disambiguate
against

  MEM[(struct vec_ *)_9 + 4B] = _8;

when looking up MEM[(const struct Ray *)&D.4309][_12].org.x; because
vn_reference_maybe_forwprop_address doesn't forward into MEM[(struct vec_ *)_9
+ 4B] as its offset is not zero:

      /* If that didn't work because the address isn't invariant propagate
         the reference tree from the address operation in case the current
         dereference isn't offsetted.  */
      if (!addr_base
          && *i_p == ops->length () - 1
          && off == 0
          /* This makes us disable this transform for PRE where the
             reference ops might be also used for code insertion which
             is invalid.  */
          && default_vn_walk_kind == VN_WALKREWRITE)
        {
          auto_vec<vn_reference_op_s, 32> tem;
          copy_reference_ops_from_ref (TREE_OPERAND (addr, 0), &tem);
          ops->pop ();
          ops->pop ();
          ops->safe_splice (tem);
          --*i_p;
          return true;

it also likely wouldn't help vn_reference_lookup_3 to do the disambiguation
as that performs just

      lhs_ops = valueize_refs_1 (lhs_ops, &valueized_anything);
      if (valueized_anything)
        {
          lhs_ref_ok = ao_ref_init_from_vn_reference (&lhs_ref,
                                                      get_alias_set (lhs),
                                                      TREE_TYPE (lhs),
lhs_ops);
          if (lhs_ref_ok
              && !refs_may_alias_p_1 (ref, &lhs_ref, true))
            return NULL;

but there is still the variable offset to cope with.  We'd need to perform
some disambiguation on lhs_ref vs. vr.

But it's not clear how to represent &D.4309[_12].org forwarded into
MEM[(struct vec_ *)_9 + 4B].  It's kind-of a COMPONENT_REF with just
a offset added.

Let's collect the improvements I have sofar in my local tree and see if they
otherwise work.