From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D3E443858CDA; Wed, 29 Mar 2023 22:41:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D3E443858CDA DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1680129713; bh=PQVBPmGYTjhCxcES3AQce97qJG//17cFET1Kk+yUicA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AFjlzJ0EqpMhvKsBxMw+X/+eZXis3y1Qq4yCZEM7M2Wc01OyEBeU4qU0Mc7tNTHkn 2/1IuBTV7Ck95hVZAEEzSn8S3VFsdgLYBTG1/xOh11qQfjgkPjmQzannmVs1z5Flpf nMrXMpp2DynJSj9Gp1bKfpJGYseArVjehqqGiKS0= From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons Date: Wed, 29 Mar 2023 22:41:52 +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: amacleod at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 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=3D109154 --- Comment #40 from Andrew Macleod --- > There is no problem with adding --params, and those are always better than > magic numbers. >=20 > Btw, I originally wondered why we don't re-compute zone1_12 because it's > in the imports of the successor (OK, the empty successors single successor > block) and expected those to trigger re-computes. Yeah, I don't like magic number either. I vaguely recall that it changed t= he footprint of something and caused linking issues with something else requir= ing complete rebuilds which annoyed some people.. but I have lost the context. Recomputes have nothing to do with imports, its all about exports. Exports drive the range engine... they are the things that change on exit to block based on the edge taken. Imports are things which can affect an export. So= in some iterative/analytical world, if the imports to a block do not change, t= he exports will not change either. Recomputes are about having an export from a block in your definition chain. This means you are only indirectly related to the export. If the export changes, then your value may also change if you can be recalculated using t= he export. This issue is fundamentally about how much effort we make into looking if y= ou can be recomputed. Its turns out the underlying engine is more efficient t= han I realized, and once we indicate it can be calculated, the calculation itse= lf is actually linear.=20 If we stick to single ssa-names dependencies, then even though the lookup is currently quadratic, for smallish numbers, its pretty minimal impact. Most cases I've seen that are of impact seem to be a sequence involving a f= ew casts. The current patchset with a depth of 5 catches the vast majority of things, and is not that expensive.=