From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 30A553858C56; Thu, 16 Nov 2023 07:33:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 30A553858C56 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1700120038; bh=zaRAyZ06d8c7dAnLNNPD5NnPY65m2gWi1nxZz4Atij4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cA5TMUCe9M0s5uocRCP/lryjdQMpLEDQO33/n5IMgLypLYfDWe2ExNnuDCpyGkm6G O64+AR4GSiQALM0or0Zbze8IibXB0o1oUPjI+YSHUgi5TvC1IMmQFqwcxtD+uqGcfm 4b/0agZ7i+/PNG7HDHZp4FvPP7fxBDvyMOIWUa7s= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/112526] [14 regression] Miscompilation of ffmpeg test for -m32 since r14-4968-g89e5d902fc55ad Date: Thu, 16 Nov 2023 07:33:57 +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: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.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=3D112526 --- Comment #12 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f158bd511df1f55ebbbc0df3dee52c4400291984 commit r14-5519-gf158bd511df1f55ebbbc0df3dee52c4400291984 Author: Jakub Jelinek Date: Thu Nov 16 08:33:18 2023 +0100 i386: Fix mov imm,%rax; mov %rdi,%rdx; mulx %rax -> mov imm,%rdx; mulx = %rdi peephole2 [PR112526] The following testcase is miscompiled on x86_64 since PR110551 r14-4968 commit. That commit added 2 peephole2s, one for mov imm,%rXX; mov %rYY,%rax; mulq %rXX -> mov imm,%rax; mulq %rYY which I believe is ok, and another one for mov imm,%rXX; mov %rYY,%rdx; mulx %rXX, %rZZ, %rWW -> mov imm,%rdx; mulx %rYY, %rZZ, %rWW which is wrong. Both peephole2s verify that %rXX above is dead at the end of the pattern, by checking if %rXX is either one of the registers overwritten in the multiplication (%rdx:%rax in the first case, the 2 destination registers of mulx in the latter case), because we no longer set %rXX to that immediate (we set %rax resp. %rdx to it instead) when the peephole2 replaces it. But, we also need to ensure that the other register previously set to the value of %rYY and newly to imm isn't used after the multiplication, and neither of the peephole= 2s does that. Now, for the first one (at least assuming in the % pattern the matching operand (i.e. hardcoded %rax resp. %rdx) after RA will alw= ays go first) I think it is always the case, because operands[2] if it must be %rax register will be overwritten by mulq writing to %rdx:%rax. But in the second case, there is no reason why %rdx couldn't be used after the pattern, and if it is (like in the testcase), we can't make those changes. So, the patch checks similarly to operands[0] that operands[2] (which o= ught to be %rdx if RA puts the % match_dup operand first and nothing swaps it afterwards) is either the same register as one of the destination regis= ters of mulx or dies at the end of the multiplication. 2023-11-16 Jakub Jelinek PR target/112526 * config/i386/i386.md (mov imm,%rax; mov %rdi,%rdx; mulx %rax -> mov imm,%rdx; mulx %rdi): Verify in define_peephole2 that operands[2] dies or is overwrit= ten at the end of multiplication. * gcc.target/i386/bmi2-pr112526.c: New test.=