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...
