Sorry should have mention the PR
On 1/23/23 12:44, Andrew MacLeod wrote:
This patch adds VREL_OTHER to represent another relation we do not
understand. It is used to represent the class fo relations arising
from floating point that are currently not represented. IN GCC 14 we
will determine exactly how to represent them, but for this release,
this should prevent us from getting things wrong at least.
if intersection produces UNDEFINED and either of the relations feeding
it were <, <=, >, or >= then it turns it to VR_OTHER. the prevents
false sides of branches from combining to produce UNDEFINED when they
end up being a known NAN.
Union is adjusted such that < >, or <= >= also produce VREL_OTHER. <
> cannot be properly represented, and <= >= was producing VARYING,
which is also not correct.
Form the testcase:
<bb 2> :
cmp1_10 = x_8(D) <= y_9(D);
cmp2_11 = x_8(D) >= y_9(D);
_3 = cmp1_10 & cmp2_11;
if (_3 != 0)
goto <bb 3>; [INV]
else
goto <bb 4>; [INV]
Relational : (x_8(D) == y_9(D))
<bb 3> :
// predicted unlikely by early return (on trees) predictor.
goto <bb 6>; [INV]
<bb 4> :
_4 = ~cmp1_10;
_5 = ~cmp2_11;
_1 = cmp1_10 | cmp2_11;
_6 = ~_1;
if (_1 != 0)
goto <bb 6>; [INV]
else
goto <bb 5>; [INV]
Relational : (x_8(D) unknown fp y_9(D))
<bb 5> :
// predicted unlikely by early return (on trees) predictor.
The intersection "fix" is represented by the relation between x and y
in BB5. Without the patch, ti would be UNDEFINED and we do not want
that.
The union fix is what prevents us from folding the condition in bb_4.
Without it, x<=y union x >=y comes out VARYING, when in fact I believe
it represents everything except a NAN.
So with this fix, all the unrepresentative relations get lumped into
VREL_OTHER so we at least don't get it wrong. For next release we can
take the time to figure out exactly how we want to proceed.
This is currently in testing on x86_64-pc-linux-gnu, and assuming it
bootstraps with no regressions (a combined patch did before splitting
it in 2), OK for trunk? OR does it need more tweaking?
Andrew
