From: "Måns Rullgård" <mans@mansr.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
Stephen Boyd <sboyd@codeaurora.org>,
linux-arm-msm@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org, Nicolas Pitre <nico@fluxnic.net>
Subject: Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions
Date: Sat, 21 Nov 2015 22:11:36 +0000 [thread overview]
Message-ID: <yw1x4mgfc89z.fsf@unicorn.mansr.com> (raw)
In-Reply-To: <6160413.CulAvzVaQj@wuerfel> (Arnd Bergmann's message of "Sat, 21 Nov 2015 22:00:16 +0100")
Arnd Bergmann <arnd@arndb.de> writes:
> On Saturday 21 November 2015 20:45:38 Måns Rullgård wrote:
>> On 21 November 2015 20:39:58 GMT+00:00, Arnd Bergmann <arnd@arndb.de> wrote:
>> >On Friday 20 November 2015 17:23:14 Stephen Boyd wrote:
>> >> This is a respin of a patch series from about a year ago[1]. I
>> >realized
>> >> that we already had most of the code in recordmcount to figure out
>> >> where we make calls to particular functions, so recording where
>> >> we make calls to the integer division functions should be easy enough
>> >> to add support for in the same codepaths. Looking back on the thread
>> >> it seems like Mans was thinking along the same lines, although it
>> >wasn't
>> >> obvious to me back then or even over the last few days when I wrote
>> >this.
>> >
>> >Shouldn't we start by allowing to build the kernel for -march=armv7ve
>> >on platforms that allow it? That would seem like a simpler change
>> >and likely generate better code for most people, except when you
>> >actually
>> >care about running the same binary kernel on older platforms.
>> >
>> >I tried to get a complete list of CPU cores with idiv, lpae and
>> >virtualization support at some point, but I don't remember the
>> >details for all Qualcomm and Marvell cores any more, to create the
>> >complete configuration matrix. IIRC, all CPUs that support
>> >virtualization also do lpae (they have to) and all CPUs that
>> >do lpae also do idiv, but the opposite is not true.
>> >
>>
>> The ARM ARM says anything with virt has idiv, lpae doesn't matter.
>
> Ok, and anything with virt also has lpae by definition. The question is
> whether we care about using idiv on cores that do not have lpae, or that
> have neither lpae nor virt.
The question is, are there any such cores? GCC doesn't know of any, but
then it's missing most non-ARM designs.
--
Måns Rullgård
mans@mansr.com
next prev parent reply other threads:[~2015-11-21 22:11 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-21 1:23 [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Stephen Boyd
2015-11-21 1:23 ` [RFC/PATCH 1/3] scripts: Allow recordmcount to be used without tracing enabled Stephen Boyd
2015-11-21 1:23 ` [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM Stephen Boyd
2015-11-21 10:13 ` Russell King - ARM Linux
2015-11-23 20:53 ` Stephen Boyd
2015-11-23 20:58 ` Steven Rostedt
2015-11-23 21:03 ` Russell King - ARM Linux
2015-11-23 21:16 ` Stephen Boyd
2015-11-23 21:33 ` Russell King - ARM Linux
2015-11-24 1:04 ` Stephen Boyd
2015-11-21 1:23 ` [RFC/PATCH 3/3] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions Stephen Boyd
2015-11-21 11:50 ` Måns Rullgård
2015-11-23 20:49 ` Stephen Boyd
2015-11-23 20:54 ` Måns Rullgård
2015-11-23 21:16 ` Stephen Boyd
2015-11-21 20:39 ` [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions Arnd Bergmann
2015-11-21 20:45 ` Måns Rullgård
2015-11-21 21:00 ` Arnd Bergmann
2015-11-21 22:11 ` Måns Rullgård [this message]
2015-11-21 23:14 ` Arnd Bergmann
2015-11-21 23:21 ` Arnd Bergmann
2015-11-22 13:29 ` Peter Maydell
2015-11-22 19:25 ` Arnd Bergmann
2015-11-22 19:30 ` Måns Rullgård
2015-11-22 19:47 ` Russell King - ARM Linux
2015-11-22 19:58 ` Arnd Bergmann
2015-11-22 20:03 ` Russell King - ARM Linux
2015-11-22 20:37 ` Arnd Bergmann
2015-11-22 20:39 ` Måns Rullgård
2015-11-22 21:18 ` Arnd Bergmann
2015-11-23 2:36 ` Nicolas Pitre
2015-11-23 8:15 ` Arnd Bergmann
2015-11-23 14:14 ` Christopher Covington
2015-11-23 15:32 ` Arnd Bergmann
2015-11-23 20:38 ` Stephen Boyd
2015-11-23 21:19 ` Arnd Bergmann
2015-11-23 21:32 ` Stephen Boyd
2015-11-23 21:57 ` Arnd Bergmann
2015-11-23 23:13 ` Stephen Boyd
2015-11-24 10:17 ` Arnd Bergmann
2015-11-24 12:15 ` Måns Rullgård
2015-11-24 13:45 ` Arnd Bergmann
2015-11-25 1:51 ` Stephen Boyd
2015-11-25 7:21 ` Arnd Bergmann
2015-11-24 0:13 ` Stephen Boyd
2015-11-24 8:53 ` Stephen Boyd
2015-11-24 10:38 ` Arnd Bergmann
2015-11-24 10:42 ` Russell King - ARM Linux
2015-11-24 12:10 ` Måns Rullgård
2015-11-24 12:23 ` Russell King - ARM Linux
2015-11-24 12:29 ` Måns Rullgård
2015-11-24 14:00 ` Russell King - ARM Linux
2015-11-24 14:03 ` Måns Rullgård
2015-11-24 10:39 ` Russell King - ARM Linux
2015-11-24 20:07 ` Stephen Boyd
2015-11-24 20:35 ` Russell King - ARM Linux
2015-11-24 21:11 ` Arnd Bergmann
2016-01-13 1:51 ` Stephen Boyd
2015-11-24 10:37 ` Russell King - ARM Linux
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=yw1x4mgfc89z.fsf@unicorn.mansr.com \
--to=mans@mansr.com \
--cc=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nico@fluxnic.net \
--cc=rostedt@goodmis.org \
--cc=sboyd@codeaurora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox