From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id ED574385E830; Tue, 16 Jun 2020 00:01:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ED574385E830 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1592265704; bh=vlj9bid9jBK6SD7zomwtsicNxCOKOhF4TscM5Oe3dfk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BV3lwcOUZoRe07xnnLl4w2nHelvC7VVItKbmDosP15yKQbzk14Z8wXvuUTMT5noZi OIDZ/bhdqGYO7hF7ttQYzCqeQN8AMkqlk4Ex9NDv9rd+cNBx9ZzRIjASMop9bOYrO3 E5v1qLzICGd5BEKrkU2kzfLBgp2igWl0YL7juWdc= From: "wilson at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/95632] Redundant zero extension Date: Tue, 16 Jun 2020 00:01:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 10.1.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: Tue, 16 Jun 2020 00:01:45 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95632 --- Comment #3 from Jim Wilson --- It isn't possible to have patterns that match only in combine. If we add a pattern to accept (xor (reg) (large constant)) then it could match in any optimization pass, and could prevent us from optimizing away redundant lui instructions. There is a representation issue here with constants. If we split them earl= y, then optimizing redundant lui is easy. If we split them late, then optimiz= ing redundant lui is hard. There are also other optimizations that may be easy= or hard depending on whether constants are split early or late. Currently, we always split constants early, and changing that will have a major impact on= the code optimization, which may be good or bad, but more likely will be good f= or some programs and bad for others. I'd rather not change this as it will be= a major project to deal with the problems caused by the change. Hence my suggestion at RTL generation time to split xor with constants differently. I have a proof of concept patch for that, but it needs a lot = of cleanup to be useful, and a lot of testing to verify that it improves code = more often than it harms code. As for ree, splitters after register allocation traditionally check reload_completed which is a global variable set near the end of the last register allocation pass. The split2 pass happens between reload and ree.= =20 Maybe moving ree before split2 would help RISC-V, but might hurt other targ= ets. Or might help for some programs and hurt for others.=