From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 748CE388B814; Mon, 2 Aug 2021 18:05:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 748CE388B814 From: "unlvsur at live dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1 Date: Mon, 02 Aug 2021 18:05:32 +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: missed-optimization X-Bugzilla-Severity: enhancement X-Bugzilla-Who: unlvsur at live 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: --- 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 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: Mon, 02 Aug 2021 18:05:32 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101466 --- Comment #15 from cqwrteur --- (In reply to rguenther@suse.de from comment #14) > On Mon, 19 Jul 2021, unlvsur at live dot com wrote: >=20 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101466 > >=20 > > --- Comment #13 from cqwrteur --- > > (In reply to Richard Biener from comment #12) > > > (In reply to Richard Biener from comment #11) > > > > With some hand-waving we could generate > > > >=20 > > > > void square(unsigned t, int *tt) > > > > { > > > > if (t<=3D4) __builtin_abort(); > > > > tt[0] =3D 0; > > > > tt[1] =3D 0; > > > > tt[2] =3D 0; > > > > tt[3] =3D 0; > > > > tt[4] =3D 0; > > > > } > > > >=20 > > > > but I don't see how it fits any existing transform? The "hand-wavi= ng" > > > > would be that __builtin_abort () since it's a known function cannot > > > > observe the dropped side-effects like tt[0] =3D 0 when t > 0. > > >=20 > > > That is, we'd sink the stores across the abort ()s because they are > > > not uses of them, then we arrive at > > >=20 > > > if (t<=3D0) __builtin_abort(); > > > if (t<=3D1) __builtin_abort(); > > > if (t<=3D2) __builtin_abort(); > > > if (t<=3D3) __builtin_abort(); > > > if (t<=3D4) __builtin_abort(); > > > tt[0] =3D 0; > > > tt[1] =3D 0; > > > tt[2] =3D 0; > > > tt[3] =3D 0; > > > tt[4] =3D 0; > > >=20 > > > where we'd somehow "thread" to a single condition (PRE tail merging > > > merges the abort () blocks and reassoc way after it manages to merge > > > the controlling conditions). > >=20 > > https://godbolt.org/z/af8nn8K4h > >=20 > > I found this to be interesting. with -fno-exceptions, all those calls a= re > > folded together. It looks -fno-exceptions hurts optimizations here. Is = that a > > bug or C++ EH truly affects the semantics here? >=20 > It's likely not "semantics" but the pass responsible likey simply gives > up on incoming EH edges. There's some long-term TODO to base that > off some more modern tooling. I do not see anything wrong to assume the semantics of __builtin_trap() and __builtin_abort() for compiler. Just like we treat memcpy or __builtin_memc= py or memmove as some kind of magic intrinsic in the compiler. Even memcpy may= be implemented by libc differently. So this optimization is technically valid.=