On Mon, Jan 23, 2023 at 6:44 PM Andrew MacLeod <amacl...@redhat.com> 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?
LGTM, I'd appreciate a 2nd eye though - you've gone through all the pecularities of combining FP relations in the PRs audit trail. Richard. > > Andrew
