From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 25A703858018; Mon, 15 Nov 2021 17:52:33 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 25A703858018
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/103252] questionable codegen with kmovd
Date: Mon, 15 Nov 2021 17:52:32 +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: 11.2.0
X-Bugzilla-Keywords: missed-optimization, ra
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: <bug-103252-4-IvKympKmzR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-103252-4@http.gcc.gnu.org/bugzilla/>
References: <bug-103252-4@http.gcc.gnu.org/bugzilla/>
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 <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2021 17:52:33 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103252

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
On https://gcc.godbolt.org/z/KG63ErzEr I don't see anything wrong, ia32 has
just a few GPRs and all of them are heavily used in the loop, so if the %k?
registers aren't slower than memory, it seems just fine to me.
For https://gcc.godbolt.org/z/15hnsb6of trunk emits
        kmovd   %ecx, %k0
        movl    __libc_tsd_CTYPE_B@gotntpoff(%ebx), %ecx
        kmovd   %k0, %eax
        movl    %gs:(%ecx), %ecx
        testb   $32, 1(%ecx,%eax,2)
where it is unclear to me why if RA made the unfortunate decision here to u=
se
%k0 doesn't e.g. postreload fix that up, it has:
(insn 221 94 95 17 (set (reg:SI 68 k0 [orig:130 c ] [130])
        (reg:SI 2 cx [orig:130 c ] [130])) "pr103252.c":81:68 77
{*movsi_internal}
     (nil))
... a few insns that don't touch %eax nor %k0
(insn 222 98 197 17 (set (reg:SI 0 ax [orig:130 c ] [130])
        (reg:SI 68 k0 [orig:130 c ] [130])) "pr103252.c":81:43 77
{*movsi_internal}
     (nil))
so why does it the unnecessary hop through another register when it could h=
ave
movl %ecx, %eax instead of the first kmovd and nothing instead of the secon=
d.=20
Those 2 are the only %k0 uses.=