From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DEA8B385AC30; Tue, 5 Oct 2021 13:59:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DEA8B385AC30 From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102540] [12 Regression] Dead Code Elimination Regression at -O3 since r12-476-gd846f225c25c5885 Date: Tue, 05 Oct 2021 13:59:13 +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: 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: 12.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 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: Tue, 05 Oct 2021 13:59:14 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102540 --- Comment #8 from Andrew Macleod --- > >=20 > > It would probably resolve an entire class of things where we don't reco= gnize an > > equivalence between a cast and a bitmask of equivalent precision. > >=20 > > This would also mean the reverse would apply.. ie if we instead branche= d on _2 > > !=3D 0 we would also understand that _6 will be non-zero. >=20 > I believe tracking known zero/one bits in addition to a range is more > useful - would that help in this case? Thats in plan and what I first thought would fix it. Reflecting on this problem however, it would only help on the zero side where all the bits are known zero, but the non-zero property we are looking for can't be reflected= by known ones or zeros..=20 Unfortunately I don't see how we can solve this particular problem by track= ing known bit values.. there wont be any known 1s or 0s in a.0_1... just a particular bit pattern that cannot occur. Another option would be if I can get a cheap enough low-opt pass of evrp (a= lso on my list) we could run it really early before things get rearranged and t= hen run the higher levels later. Anyway, I'll keep thinking about this...=