From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B31463860C39; Thu, 29 Oct 2020 22:49:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B31463860C39 From: "wilson at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool Date: Thu, 29 Oct 2020 22:49:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: other X-Bugzilla-Version: 10.2.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: wilson at gcc dot gnu.org 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: Thu, 29 Oct 2020 22:49:29 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97417 --- Comment #7 from Jim Wilson --- That patch is basically correct. I would suggest using gen_lowpart instead= of gen_rtx_SUBREG as a minor cleanup. It will do the same thing, and is short= er and easier to read. There is one problem here that you can't generate new pseudo registers duri= ng register allocation, or after register allocation is complete. So you need= to disable this optimization in this case. You can do that by adding a check = for can_create_pseudo_p (). This is already used explicitly in one place in riscv_legitimize_move and implicitly in some subfunctions, and is used in t= he arm.md movqi pattern. The next part is testing the patch. We need some correctness testing. You= can just run the gcc testsuite for that. And we need some code size/performance testing. I'd suggest compiling some code with and without the patch and ch= eck function sizes and look for anything that got bigger with the patch, and ch= eck to see if it is a problem. I like to use the toolchain libraries like libc= .a and libstdc++.a since they are being built anways, but using a nice benchma= rk is OK also as long as it is big enough to stress the compiler. If the patch passes testing, then we can look at expanding the scope to han= dle more modes, and also handle MEM dest in addition to REG dest. Yes, we can discuss this Monday.=