[RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

[Måns Rullgård]

Arnd Bergmann <arnd at 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 at 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 at mansr.com