From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
Date: Mon, 11 Nov 2013 18:34:08 -0800 [thread overview]
Message-ID: <528193A0.7050505@codeaurora.org> (raw)
In-Reply-To: <alpine.LFD.2.10.1311092357090.2314@knanqh.ubzr>
On 11/09/13 21:03, Nicolas Pitre wrote:
> Bah..... NAK. We are doing runtime patching of the kernel for many
> many things already. So why not do the same here?
static keys are a form of runtime patching, albeit not as extreme as
you're suggesting.
>
> The obvious strategy is to simply overwrite the start of the existing
> __aeabi_idiv code with the "sdiv r0, r0, r1" and "bx lr" opcodes.
>
> Similarly for the unsigned case.
I was thinking the same thing when I wrote this, but I didn't know how
to tell the compiler to either inline this function or to let me inilne
an assembly stub with some section magic.
>
> That let you test the hardware capability only once during boot instead
> of everytime a divide operation is performed.
The test for hardware capability really isn't done more than once during
boot. The assembly is like so at compile time
00000000 <__aeabi_idiv>:
0: nop {0}
4: b 0 <___aeabi_idiv>
8: sdiv r0, r0, r1
c: bx lr
and after we test and find support for the instruction it will be
replaced with
00000000 <__aeabi_idiv>:
0: b 8
4: b 0 <___aeabi_idiv>
8: sdiv r0, r0, r1
c: bx lr
Unfortunately we still have to jump to this function. It would be great
if we could inline this function at the call site but as I already said
I don't know how to do that.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@codeaurora.org>
To: Nicolas Pitre <nico@fluxnic.net>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
"Jean-Christophe PLAGNIOL-VILLARD" <plagnioj@jcrosoft.com>,
"Christopher Covington" <cov@codeaurora.org>,
"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
"Måns Rullgård" <mans@mansr.com>,
"Rob Herring" <robherring2@gmail.com>
Subject: Re: [PATCH v2] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
Date: Mon, 11 Nov 2013 18:34:08 -0800 [thread overview]
Message-ID: <528193A0.7050505@codeaurora.org> (raw)
In-Reply-To: <alpine.LFD.2.10.1311092357090.2314@knanqh.ubzr>
On 11/09/13 21:03, Nicolas Pitre wrote:
> Bah..... NAK. We are doing runtime patching of the kernel for many
> many things already. So why not do the same here?
static keys are a form of runtime patching, albeit not as extreme as
you're suggesting.
>
> The obvious strategy is to simply overwrite the start of the existing
> __aeabi_idiv code with the "sdiv r0, r0, r1" and "bx lr" opcodes.
>
> Similarly for the unsigned case.
I was thinking the same thing when I wrote this, but I didn't know how
to tell the compiler to either inline this function or to let me inilne
an assembly stub with some section magic.
>
> That let you test the hardware capability only once during boot instead
> of everytime a divide operation is performed.
The test for hardware capability really isn't done more than once during
boot. The assembly is like so at compile time
00000000 <__aeabi_idiv>:
0: nop {0}
4: b 0 <___aeabi_idiv>
8: sdiv r0, r0, r1
c: bx lr
and after we test and find support for the instruction it will be
replaced with
00000000 <__aeabi_idiv>:
0: b 8
4: b 0 <___aeabi_idiv>
8: sdiv r0, r0, r1
c: bx lr
Unfortunately we still have to jump to this function. It would be great
if we could inline this function at the call site but as I already said
I don't know how to do that.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2013-11-12 2:34 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-08 23:00 [PATCH v2] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Stephen Boyd
2013-11-08 23:00 ` Stephen Boyd
2013-11-09 6:46 ` Matt Sealey
2013-11-09 6:46 ` Matt Sealey
2013-11-09 18:20 ` Måns Rullgård
2013-11-09 18:20 ` Måns Rullgård
2013-11-12 1:23 ` Stephen Boyd
2013-11-12 1:23 ` Stephen Boyd
2013-11-10 5:03 ` Nicolas Pitre
2013-11-10 5:03 ` Nicolas Pitre
2013-11-12 2:34 ` Stephen Boyd [this message]
2013-11-12 2:34 ` Stephen Boyd
2013-11-12 11:28 ` Måns Rullgård
2013-11-12 11:28 ` Måns Rullgård
2013-11-12 14:01 ` Nicolas Pitre
2013-11-12 14:01 ` Nicolas Pitre
2013-11-12 14:04 ` Russell King - ARM Linux
2013-11-12 14:04 ` Russell King - ARM Linux
2013-11-12 14:16 ` Nicolas Pitre
2013-11-12 14:16 ` Nicolas Pitre
2013-11-12 14:17 ` Ben Dooks
2013-11-12 14:17 ` Ben Dooks
2013-11-12 14:32 ` Nicolas Pitre
2013-11-12 14:32 ` Nicolas Pitre
2013-11-12 14:40 ` Måns Rullgård
2013-11-12 14:40 ` Måns Rullgård
2013-11-12 14:55 ` Nicolas Pitre
2013-11-12 14:55 ` Nicolas Pitre
2013-11-12 15:20 ` Nicolas Pitre
2013-11-12 15:20 ` Nicolas Pitre
2013-11-12 18:03 ` Måns Rullgård
2013-11-12 18:03 ` Måns Rullgård
2013-11-12 14:22 ` Måns Rullgård
2013-11-12 14:22 ` Måns Rullgård
2013-11-12 14:36 ` Nicolas Pitre
2013-11-12 14:36 ` Nicolas Pitre
2013-11-11 7:46 ` Uwe Kleine-König
2013-11-11 7:46 ` Uwe Kleine-König
2013-11-12 2:35 ` Stephen Boyd
2013-11-12 2:35 ` Stephen Boyd
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=528193A0.7050505@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.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.