[Bug tree-optimization/62173] [5.0 regression] 64bit Arch can't ivopt while 32bit Arch can

[amker at gcc dot gnu.org]

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

--- Comment #33 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #32)
> "So I take the other way around by passing the IV's ssa_name into
> scev_probably_wraps_p along call sequence
> "idx_find_step->convert_affine_scev->scev_probably_wraps".  Since the IV's
> ssa_name is tagged with right range information, we can use it when proving
> there is no overflow/wrap in src scev."
> 
> I'm not sure that this is always correct - is the name we ask
> scev_probably_wraps
> on always equal to the IV?  Is it never offsetted?  I think that we need a
> soultion that involves tracking of range information all the way through
> SCEV analysis and thus have it on the CHREC itself.

Yes this is wanted, but I think it's another improvement.  In IVOPT, we don't
need to inherit range information from CHREC from SCEV.  The structure iv has
field ssa_name pointing to the ssa var.  We can use this var's range
information in IVOPT.  Well, the only problem is that field is reset in
record_use.

Moreover, for this PR, it isn't range information of IV's var that we want. 
What we want is the range information of IV's base var.  As in below dump:

  <bb 16>:
  # RANGE [0, 10] NONZERO 15
  # d_26 = PHI <i_6(D)(15), d_13(17)>
  # RANGE [0, 9] NONZERO 15
  d_13 = d_26 + -1;
  _14 = A[d_26];
  # RANGE [0, 255] NONZERO 255
  _15 = (int) _14;
  # USE = nonlocal
  # CLB = nonlocal
  foo (_15);
  if (d_13 != 0)
    goto <bb 17>;
  else
    goto <bb 3>;

  <bb 17>:
  goto <bb 16>;

We really want to take advantage of i_6(D)'s range information, which isn't an
IV.  And it's possible the range information of i_6(D) may not hold in other
part of code other than this loop.
I had patches for last two issues, will send for review later.

> 
> 
> As for the other things - yes, there are multiple places where we lose sign
> information and STEP is just one example (I _think_ I made DR_STEP for
> data-ref analysis forced signed at some point).
> 
> Promoting the array index to a word_mode type sounds interesting, it of
> course
> only makes sense for previously signed types - otherwise you just get another
> conversion in the way.  Of course with GCC you will likely run into the issue
> that this promotion is cancelled by the forced conversion to sizetype, so
> you'll end up with unsigned word_mode again.  Btw - this was kind of my
> suggestion with making get_inner_reference return *POFFSET as ssizetype type,
> not sizetype (callers might not expect this, so for experimenting just
> wrap get_inner_reference in sth converting that back to sizetype for all
> callers but IVOPTs and tree-affine.c (and eventually
> tree-scalar-evolution.c)).

I now don't think this PR is caused by the different type precision issue. 
However it's related to type conversion and how SCEV handles it in GCC.  I need
more study to fully understand the issue, so shouldn't saying too much in case
it's wrong...