From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2995D385780A; Thu, 11 Nov 2021 14:54:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2995D385780A From: "aldyh at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/103188] [12 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault Date: Thu, 11 Nov 2021 14:54:09 +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: 12.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh at redhat dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2021 14:54:10 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103188 Aldy Hernandez changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aldyh at redhat dot com, | |amacleod at redhat dot com --- Comment #9 from Aldy Hernandez --- (In reply to Richard Biener from comment #3) > Caused by g:e82c382971664d6fd138cc36020db4b1a91885c6, the call tree roots= at >=20 > #666394 0x00000000015f2170 in should_duplicate_loop_header_p ( > header=3D, loop=3D0x7ffff66aa9f0,=20 > limit=3D0x7fffffffd97c, query=3D0x3fccb70) > at /home/rguenther/src/gcc3/gcc/tree-ssa-loop-ch.c:83 > 83 && !entry_loop_condition_is_static (loop, query)) >=20 > likely ranger is confused by the intermediate IL (from other loops header > copying), the IL is kept partly not in up-to-date SSA form (because runni= ng > update_ssa is costly so we run it once after doing all header copying in > a function). Ughh, yeah. Ranger won't do well with in-flight SSA. I think we can do ok with minimally changing IL like what evrp does with the substitute and fold engine, but we expect things quite sane. When working on this patch I saw the call to gimple_duplicate_sese_region w= ould increase the number of BBs, which caused problems in the cache and Andrew fixed. I thought that was it for issues, obviously not. >=20 > In this case we applied loop header copying to loop 4 containing loop 5 > which we are now processing. >=20 > Not up-to-date SSA form means that while SSA defs are copied, the SSA uses > in a stmt are still old and _not_ replaced with their current definition. > There's only so much you can do with such IL, in particular invoking SCEV > isn't among that. >=20 > You can actually check whether a SSA name may be affected by checking > name_registered_for_update_p. SCEV doesn't do that. Hmmm, useful. >=20 > In the end that means that we'd have to do the ranger analysis before > actually applying the header copying. >=20 > Note that the current place of the >=20 > /* Avoid loop header copying when optimizing for size unless we can > determine that the loop condition is static in the first > iteration. */ > if (optimize_loop_for_size_p (loop) > && !loop->force_vectorize > && !entry_loop_condition_is_static (loop, query)) > { >=20 > is off in any case, since we iterate on blocks to copy, instead it should > be done exactly once per loop. So we can do the "head", up until this > and the very first should_duplicate_loop_header_p first for each loop, > recording candidates in a vector and in a second loop process them all, > not doing the already done entry_loop_condition_is_static. >=20 > Let me cook up a patch to do that. Thanks for fixing this!=