https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123205
Bug ID: 123205
Summary: VRP recomputation is too aggressive
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: amacleod at redhat dot com
Reporter: amacleod at redhat dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
Created attachment 63087
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63087&action=edit
Problem testcase
GORI often recomputes a range for the LHS of an expression if the RHS has
changed on conditional paths. It is currently too aggressive and recomputes
some things that should not be recomputed.
In this case, the program starts with
<bb 2> :
y_4 = __builtin_constant_p (x_3(D));
and then later gets to
<bb 5> :
if (x_3(D) == 24)
goto <bb 6>; [INV]
else
goto <bb 9>; [INV]
<bb 6> :
if (y_4 != 0)
goto <bb 7>; [INV]
else
goto <bb 8>; [INV]
<bb 7> :
isconst (y_4, x_3(D));
goto <bb 9>; [INV]
<bb 8> :
nonconst (y_4, x_3(D));
GORI see's that x_3 is more refined in the condition, and recomputes the range
of y_4 using x_3 = [24,24]
This now evaluates to [1,1] and we produce the wrong result by calling isconst
(1, 24) instead of nonconst (0, x_4);
Currently gori's check for recomputation is
if (is_a<gphi *> (stmt) || gimple_has_side_effects (stmt))
return false
This means it assume it can recompute everything else.
Most of the time this is harmless, as recomputing the result of an arbitrary
non range-op statement is likely to result in the same range. But this does
demonstrate the danger is not NIL. Additionally, its probably a waste of time
as well.
