[Bug tree-optimization/82369] "optimizes" indexed addressing back into two pointer increments

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

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

--- Comment #3 from amker at gcc dot gnu.org ---
Given IR dump before IVOPTs:
  <bb 2> [15.00%] [count: INV]:
  _1 = dst_12(D) + bytes_13(D);
  end_dst_14 = (uintptr_t) _1;
  srcu_16 = (uintptr_t) src_15(D);
  dstu_17 = (uintptr_t) dst_12(D);
  _2 = dstu_17 * 2;
  _3 = srcu_16 - _2;

  <bb 3> [100.00%] [count: INV]:
  # dstu_10 = PHI <dstu_17(2), dstu_22(4)>
  _4 = dstu_10 * 2;
  _5 = _3 + _4;
  _6 = (const __m128i_u * {ref-all}) _5;
  _25 = *_6;

When ivopts tries to find address type IV for "*_6", the base it has is like:
  (const __m128i_u * {ref-all}) ((uintptr_t) dst_12(D) * 2 + _3)
If we do more aggressive expansion for "_3", we could have:
  (const __m128i_u * {ref-all}) (srcu_16)

So without the expansion, we can't find the base object for the address in
alloc_iv, that's why we failed to classify _6 as an address type IV.  As a
result, addressing mode is not considered in choosing candidate, thus wrong
candidate chosen in the end.

OTOH, we surely don't want to do aggressive expansion because that introduces
more code into loop.  One possible fix is to do aggressive expansion for
analysis purpose, rather than unconditionally (or for code generation purpose).
 For example, we can try aggressive expansion when alloc_iv fails to find base
object, see if it can do better.

Thanks,
bin