From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5FB403857BA4; Mon, 10 Jul 2023 10:33:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5FB403857BA4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1688985231; bh=s+dLzP2KDmH5GduzA6fnMmDS3DXezmBVoB3w3EbXCyU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qxTlXv8DbryqE+7NNcT+06lg7zTONcFXhjzl4WvfPkh9+sXXH3r0ZmDTgvBcauhdR IJAVpaLt5VEnueHPtdaop54sfMOnw/SSWHvCOTZePbahml+XE6fDBuXhEDEH4w4H85 JvFnprC1JYuH9Ds6OclovmfLdrEMAoBfUmpxz+as= From: "tnfchris at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons Date: Mon, 10 Jul 2023 10:33:49 +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 X-Bugzilla-Severity: normal X-Bugzilla-Who: tnfchris at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: tnfchris at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.2 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=3D109154 --- Comment #61 from Tamar Christina --- (In reply to Richard Biener from comment #60) > (In reply to Tamar Christina from comment #59) > > after ifcvt we end up with: > >=20 > > _162 =3D chrg_init_70 * iftmp.8_76; > > _164 =3D ABS_EXPR <_162>; > > _167 =3D -_164; > > _ifc__166 =3D distbb_74 < iftmp.0_97 ? _167 : 0.0; > > prephitmp_169 =3D distbb_74 >=3D 0.0 ? _ifc__166 : _168; > >=20=20=20 > > instead of > >=20 > > _160 =3D chrg_init_75 * iftmp.8_80; > > prephitmp_161 =3D distbb_79 < 0.0 ? chrg_init_75 : _160; > > _164 =3D ABS_EXPR ; > > _166 =3D -_164; > > prephitmp_167 =3D distbb_79 < iftmp.0_96 ? _166 : 0.0; > >=20 > > previously we'd make COND_MUL and COND_NEG and so don't need a VCOND in= the > > end, > > now we select after the multiplication, so we only have a COND_NEG foll= owed > > by a VCOND. > >=20 > > This is obviously worse, but I have no idea how to recover it. Any ide= as? >=20 > None. This is with -O3, right? Can you try selectively disabling parts > of PRE with -fno-tree-partial-pre -fno-code-hoisting? But I suspect it's > the improvement for general PRE that we hit here. >=20 Those don't seem to make a difference sadly. > One idea that was always floating around was to move PRE after loop opts > like we did with predcom. But the no PRE before loop will likely hurt as > well > so we might instead want to limit PRE when it involves generating > constants in PHIs and schedule another PRE after loop opts (at some cost > then). It's something to experiment with ... It looks like `-fno-tree-pre` does the trick, but then of course, messes up elsewhere. The conditional statement seem to stay in the most complicated = form possible in scalar code. I'll try to track down what to turn off and experiment with a pre2 after ve= ct. Is before predcom a good place?=