https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104530
--- Comment #2 from Andrew Macleod <amacleod at redhat dot com> ---
mmm. tricky.
Imports: b.0_1 d.3_7
Exports: b.0_1 _2 _3 d.3_7 _8
_2 : b.0_1(I)
_3 : b.0_1(I) _2
_8 : b.0_1(I) _2 _3 d.3_7(I)
<bb 2> :
b.0_1 = b;
_2 = b.0_1 == 0B;
_3 = (int) _2;
c = _3;
_5 = *b.0_1; <<-- from this point b.0_1 is [+1, +INF]
a = _5;
d.3_7 = d;
_8 = _3 % d.3_7;
if (_8 != 0)
goto <bb 6>; [INV]
else
goto <bb 5>; [INV]
This is a bit at conflict with the "lets be safe" approach without pre-scanning
the block for lack of throwing stmts. Although that's really just a half
measure since you can construct more complicated blocks with a mix.
Im experimenting with marking values as stale for all exports of the block
which are dependant on the value we set to non null. ie, _2, _3 and _8
Then when we ask for a range of that name AFTER the de-reference, it will
recompute it. The use of _3 in computing _8 is then "stale", and will be
re-evaluated.
Simple in concept, but I'm encountering an interaction with how we currently
set the global values for the end of the pass, and although I can recompute _2
fine, it is also setting the global value of _2 to [0,0], which is not what we
want. Works for this case, but returns us to the same situation we had before
if there is a call in the block.
Im continuing to look at it. Easy fix in the next release since we are going
to change the way we export globals outside the pass... but we shall see about
this release whether I can keep it contained.
