From: Jisheng Zhang <jszhang@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arm64: save movk instructions in mov_q when the lower 16|32 bits are all zero
Date: Thu, 28 Jul 2022 23:17:38 +0800 [thread overview]
Message-ID: <YuKokvBjDxATePpH@xhacker> (raw)
In-Reply-To: <YuKh2pmJC6/17Riy@xhacker>
On Thu, Jul 28, 2022 at 10:49:02PM +0800, Jisheng Zhang wrote:
> On Wed, Jul 27, 2022 at 08:15:11AM -0700, Ard Biesheuvel wrote:
> > On Sat, 9 Jul 2022 at 01:58, Jisheng Zhang <jszhang@kernel.org> wrote:
> > >
> > > Currently mov_q is used to move a constant into a 64-bit register,
> > > when the lower 16 or 32bits of the constant are all zero, the mov_q
> > > emits one or two useless movk instructions. If the mov_q macro is used
> > > in hot code path, we want to save the movk instructions as much as
> > > possible. For example, when CONFIG_ARM64_MTE is 'Y' and
> > > CONFIG_KASAN_HW_TAGS is 'N', the following code in __cpu_setup()
> > > routine is the pontential optimization target:
> > >
> > > /* set the TCR_EL1 bits */
> > > mov_q x10, TCR_MTE_FLAGS
> > >
> > > Before the patch:
> > > mov x10, #0x10000000000000
> > > movk x10, #0x40, lsl #32
> > > movk x10, #0x0, lsl #16
> > > movk x10, #0x0
> > >
> > > After the patch:
> > > mov x10, #0x10000000000000
> > > movk x10, #0x40, lsl #32
> > >
> > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
> >
> > This is broken for constants that have 0xffff in the top 16 bits, as
> > in that case, we will emit a MOVN/MOVK/MOVK sequence, and omitting the
> > MOVKs will set the corresponding field to 0xffff not 0x0.
>
> Thanks so much for this hint. I think you are right about the 0xffff in
> top 16bits case.
>
the patch breaks below usage case:
mov_q x0, 0xffffffff00000000
I think the reason is mov_q starts from high bits, if we change the
macro to start from LSB, then that could solve the breakage. But this
needs a rewrite of mov_q
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Jisheng Zhang <jszhang@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arm64: save movk instructions in mov_q when the lower 16|32 bits are all zero
Date: Thu, 28 Jul 2022 23:17:38 +0800 [thread overview]
Message-ID: <YuKokvBjDxATePpH@xhacker> (raw)
In-Reply-To: <YuKh2pmJC6/17Riy@xhacker>
On Thu, Jul 28, 2022 at 10:49:02PM +0800, Jisheng Zhang wrote:
> On Wed, Jul 27, 2022 at 08:15:11AM -0700, Ard Biesheuvel wrote:
> > On Sat, 9 Jul 2022 at 01:58, Jisheng Zhang <jszhang@kernel.org> wrote:
> > >
> > > Currently mov_q is used to move a constant into a 64-bit register,
> > > when the lower 16 or 32bits of the constant are all zero, the mov_q
> > > emits one or two useless movk instructions. If the mov_q macro is used
> > > in hot code path, we want to save the movk instructions as much as
> > > possible. For example, when CONFIG_ARM64_MTE is 'Y' and
> > > CONFIG_KASAN_HW_TAGS is 'N', the following code in __cpu_setup()
> > > routine is the pontential optimization target:
> > >
> > > /* set the TCR_EL1 bits */
> > > mov_q x10, TCR_MTE_FLAGS
> > >
> > > Before the patch:
> > > mov x10, #0x10000000000000
> > > movk x10, #0x40, lsl #32
> > > movk x10, #0x0, lsl #16
> > > movk x10, #0x0
> > >
> > > After the patch:
> > > mov x10, #0x10000000000000
> > > movk x10, #0x40, lsl #32
> > >
> > > Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
> >
> > This is broken for constants that have 0xffff in the top 16 bits, as
> > in that case, we will emit a MOVN/MOVK/MOVK sequence, and omitting the
> > MOVKs will set the corresponding field to 0xffff not 0x0.
>
> Thanks so much for this hint. I think you are right about the 0xffff in
> top 16bits case.
>
the patch breaks below usage case:
mov_q x0, 0xffffffff00000000
I think the reason is mov_q starts from high bits, if we change the
macro to start from LSB, then that could solve the breakage. But this
needs a rewrite of mov_q
next prev parent reply other threads:[~2022-07-28 15:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-09 8:48 [PATCH] arm64: save movk instructions in mov_q when the lower 16|32 bits are all zero Jisheng Zhang
2022-07-09 8:48 ` Jisheng Zhang
2022-07-19 18:13 ` Will Deacon
2022-07-19 18:13 ` Will Deacon
2022-07-26 13:44 ` Jisheng Zhang
2022-07-26 13:44 ` Jisheng Zhang
2022-07-27 8:35 ` Will Deacon
2022-07-27 8:35 ` Will Deacon
2022-07-27 15:15 ` Ard Biesheuvel
2022-07-27 15:15 ` Ard Biesheuvel
2022-07-28 14:48 ` Jisheng Zhang
2022-07-28 14:48 ` Jisheng Zhang
2022-07-28 15:17 ` Jisheng Zhang [this message]
2022-07-28 15:17 ` Jisheng Zhang
2022-07-28 15:40 ` Ard Biesheuvel
2022-07-28 15:40 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YuKokvBjDxATePpH@xhacker \
--to=jszhang@kernel.org \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.