From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C5CF73858C52; Thu, 19 Jan 2023 20:00:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C5CF73858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1674158443; bh=TLbli5N+uEOaMUfH74h6vG/sP+8LwfgUCio7m/NULok=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WLzcwEt9v7y4zRTmTYndTmAr3HqxRhrd9PWZUGBEtR/d5JWLg3L4zceHb2TNwcC7T korIZiBJ0Ma7eINEWp4dMJvrMLqMi1s0VloMXkr/tUdaoSZuj8ceefLA0O0VEPMsNU BrlCHoNVljLN80K0P9OhHGjjcF+jkoyulrx/52NA= From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures Date: Thu, 19 Jan 2023 20:00:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: missed-optimization, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108447 --- Comment #17 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #15) > I went through the whole rr_{intersect,union}_table tables and I think ju= st > --- gcc/value-relation.cc.jj 2023-01-02 09:32:42.088000605 +0100 > +++ gcc/value-relation.cc 2023-01-19 16:20:06.490126901 +0100 > @@ -115,7 +115,7 @@ relation_kind rr_union_table[VREL_LAST][ > { VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, > VREL_VARYING, VREL_VARYING, VREL_VARYING }, > // VREL_UNDEFINED > - { VREL_VARYING, VREL_LT, VREL_LE, VREL_GT, VREL_GE, VREL_UNDEFINED, > + { VREL_VARYING, VREL_UNDEFINED, VREL_LT, VREL_LE, VREL_GT, VREL_GE, > VREL_EQ, VREL_NE }, > // VREL_LT > { VREL_VARYING, VREL_LT, VREL_LT, VREL_LE, VREL_NE, VREL_VARYING, VREL= _LE, > is really wrong for the integral/pointer relations (plus the question what > to do with the VREL_PE* relations and whether they need to be in the tabl= es > or punted on by the caller somehow). THat was my conclusions as well. As for the PE's.. it seemed easier just to leave the partial equivalences there as the table only grows from 64 to 144 entries, and in the grand sche= me seemed easier than trying to add runtime checks for relation kind ranges ju= st to avoid those few extra words.=20=20 Besides, if we ever end up with x !=3D y when there is a partial equivalenc= e, we may also be able to conclude x > y or something else.. just left the window open for exploration. >=20 > Now, when considering the relations in the fp with NAN meaning they have = in > C/C++ > (and assuming we don't try to replace say two actual comparisons in the IL > with one > with different exception behavior), the only relations in the tables which > are true for unordered operand(s) are VREL_VARYING and VREL_NE. Maybe I > miss something, but I can't think of an inappropriate intersection - > VREL_VARYING intersects anything is anything, > VREL_VARYING intersect VREL_VARYING is the only one that gives VREL_VARYI= NG, > VREL_{VARYING,NE} intersect VREL_NE or vice versa the only one that gives > VREL_NE > and VREL_UNDEFINED returned only from intersections of anything and > VREL_UNDEFINED, or > LT/LE/GT/GE vs. each other where there is no overlap (but in that case > neither allows NANs), LT/GT vs. EQ (ditto) and EQ vs. NE (one relation > doesn't allow NAN but the other does, so they aren't allowed. > As for unions - LT U GT or vice versa is incorrectly NE, should be LAST or > LTGT or some other way how to express we can't express it. LT U GE or LE U > GT or LE U GE or vice versa are incorrectly VARYING, when they are togeth= er > ORDERED (so again, need some way how to express that). Can't find anythi= ng > else wrong. > But unless we use VR_UNKNOWN or VR_LAST or whatever to stand for something > we really don't know how to handle, we'd need the various combinations th= at > tree.def has on top of the basics, LTGT, UNORDERED, ORDERED, UNLT, UNLE, > UNGT, UNGE and UNEQ. For this release, I wouldn't want to add too much extra stuff. Im inclined = to handle this pretty much where the problems arise as I think it is fairly localized. For the next release, I'm inclined to enhance the oracle and relations such that any range class can specify its own relation sets.. so irange (and most others) would use a set which implements what we have, and we could introdu= ce a floating point relation set which includes something like "<>" and "<=3D>" = and we can work out what that looks like to cover exactly what we need to model.= =20=20 That way we can model slight behaviour changes more easily.=