https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #10)
> It is not, because it emits a false positive on a fairly common code.
> Anyway, if bb3 jumps to bb4, then bb3 should have in the ranger assertion
> that in bb3 ret_17 is 0 (it is on the true branch of the ret_17 == 0 &&
> something test),
> so for the PHI, while it is or, it is either 2->4 is the executable edge and
> then ret_7 == 0 implies ret_17 == 0, or 3->4 is the executable edge and then
> ret_17 == 0 too because that was what was the assertion in bb 3. But
> arguably it isn't a very common case for PHIs. So, either the ranger can
> have special case for something like that, or the warning code can.
I dont follow what you guys are looking at. so I looked in EVRP and i see:
ret_17 = realloc (ptr_14(D), size_15(D));
_1 = ret_17 == 0B;
_2 = size_15(D) == 0;
_3 = _1 & _2;
if (_3 != 0)
goto <bb 3>; [INV]
else
goto <bb 4>; [INV]
2->3 (T) ret_17 : void * [0B, 0B]
=========== BB 3 ============
_2 _Bool [1, 1]
size_15(D) size_t [0, 0]
<bb 3> :
ret_19 = realloc (ptr_14(D), 1);
=========== BB 4 ============
Imports: ret_7
Exports: ret_7
_2 _Bool VARYING
size_15(D) long unsigned int VARYING
<bb 4> :
# ret_7 = PHI <ret_17(2), ret_19(3)>
if (ret_7 == 0B)
goto <bb 5>; [INV]
So you are saying that ret_17 is 0 if we go 2->3, then 3->4 and set ret_7 to
ret_19.
And looking backwards, if ret_7 == 0, then ret_7 is zero which implies that
ret_17 was zero on the path 2->4 if we came that way
and therefore, if we take the branch 4->5, that ret_17 is 0 ?
Thats not happening any time soon.
Theres way to much conditional context. Basic data flow says we track ret_17
as [0,0] on 2->3 and VARYING on 2->4
BB4 is also a merge point since 3->4, so the means, based on data flow, that
ret_17 is now VARYING again.
THe diamond has ended, contextual range information is gone.
First, PHI arguments are not exports from a block, their aggregator the PHI
def is... and there it ends. the computational complexities of generically
doing arguments are exponential, esepcially since we know nothing about the
edge taken. You need to see some of the crazy PHIs out there.
What you are suggesting here is that because the PHI which uses ret_17 on one
path must be zero (or whatever range) , and it happens to be zero on the other
path, we must therefore know conclusively that it is also zero.
My guess is this would be fairly uncommon.
Its possible down the road that we can use the gori unwinding to analyze ranges
which end a PHI. Winding back from
if (ret_7 == 0B)
we get [0,0] = PHI <ret_17(2), ret_19(3)> that we can teach gori or some other
unit about PHIS (we do not understand them yet since GORI is purely a basic
block concept) to make queries about ret_17 on each edge.. even 3->4 for no
apparent reason, except that we asked about ret_17. Union them all together
and see what happens. I'll keep it in mind, but that is not a high priority.
You can forget about it for this release tho :-) Besides, the information
ranger is providing shouldn't be any different than what we got before...
ranger doesn't know anything, neither did previous versions. This isnt a "loss
of information" or even a "too good of information" situation. Its basically
the same as before is it not?
