From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A98333858D39; Wed, 9 Nov 2022 15:37:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A98333858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1668008239; bh=5or56CIwbdReIpIY6aN4cn8x8hCcDYXwkhrePPb0D2o=; h=From:To:Subject:Date:From; b=JfCZFfBCzvi51/ggihRSN6mvQoBFfAw0iIrfOSpwrnAIbA3uuehu4gSuOCcYROlmz mQgCQk/Mc5L+xqCAL14NMZ1cA7G2795kYHyT/jEnlVX76XImiYQHFCCKnp4bfym2LM ZMqMzIOgNRTfPKo4C/g6QZChv3uJCGC+c96pLB88= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107591] New: range-op{,-float}.cc for x * x Date: Wed, 09 Nov 2022 15:37:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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=3D107591 Bug ID: 107591 Summary: range-op{,-float}.cc for x * x Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- int foo (int x) { if (x < -13 || x > 26) return -1; return x * x; } results in x_4(D) : [irange] int [-13, 26] _5 : [irange] int [-338, 676] That is unnecessarily pessimized, because it only computes [-13, 26] * [-13, 26] range without taking into account that both operands are the same. For the powi (x, 2) case the range is actually [0, 26 * 26], i.e. we should= n't do a cross product for it, just compute the -13 * -13, 0 * 0 (if 0 is in the range) and 26 * 26 products and form from that the range (I admit I haven't thought about unsigned or wrapping stuff). On the PR107569 testcase it is on frange: _3 =3D u_2(D)->x; _6 =3D _3 * _3; _7 =3D u_2(D)->y; _8 =3D _7 * _7; _9 =3D _6 + _8; if (_9 u>=3D 0.0) If we don't know anything further about u_2(D)->x and u_2(D)->y, VARYING * VARYING is [0, +Inf] +-NAN, added twice is the same (note, unless -fno-signed-zeros, it should be really [+0, +Inf] +-NAN, not [-0, +Inf] +-N= AN, but it doesn't matter for the u>=3D 0.0 comparison). And then we can fold u>=3D 0.0 to true.=