From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BA896385800F; Mon, 26 Sep 2022 17:25:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BA896385800F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1664213125; bh=I9kfkxW9zld/qT2Gdhq/ofbYCrj28CJBnYt3kDBFM1E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=uEu3u30NEuYLqSZ9H0vjFn+Y8q3IvQniPk0gD75HIz3UdUJt0HqJdLMHRdidGocwg s0SRYFeDv+dZn7hurn4lL7F634iZ84kgwxin3SHOJnjUYa+P8f6X4kOfGu+8LXM/NQ I/BUSlVK/5X7C2NocvEIaOOkgGXXkaHlkUqfUa9U= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107009] [13 Regression] massive unnecessary code blowup in vectorizer Date: Mon, 26 Sep 2022 17:25:25 +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: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: P1 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=3D107009 --- Comment #10 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:5e77d4082fa845f1182641a93cfbae71984244d2 commit r13-2880-g5e77d4082fa845f1182641a93cfbae71984244d2 Author: Aldy Hernandez Date: Fri Sep 23 19:47:19 2022 +0200 Optimize [0 =3D x & MASK] in range-ops. For [0 =3D x & MASK], we can determine that x is ~MASK. This is something we're picking up in DOM thanks to maybe_set_nonzero_bits, but is something we should handle natively. This is a good example of how much easier to maintain the range-ops entries are versus the ad-hoc pattern matching stuff we had to do before. For the curious, compare the changes to range-op here, versus maybe_set_nonzero_bits. I'm leaving the call to maybe_set_nonzero_bits until I can properly audit it to make sure we're catching it all in range-ops. It won't hurt, since both set_range_info() and set_nonzero_bits() are intersect operations, so we'll never lose information if we do both. PR tree-optimization/107009 gcc/ChangeLog: * range-op.cc (operator_bitwise_and::op1_range): Optimize 0 =3D= x & MASK. (range_op_bitwise_and_tests): New test.=