Re: [PATCH 2/2] tree-optimization/108447 - Add VREL_OTHER for FP unsupported relations.

[Andrew MacLeod <amacleod@redhat.com>]

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