lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 21 Nov 2015 22:11:36 +0000
From:	Måns Rullgård <mans@...sr.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Stephen Boyd <sboyd@...eaurora.org>,
	linux-arm-msm@...r.kernel.org,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, Nicolas Pitre <nico@...xnic.net>
Subject: Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

Arnd Bergmann <arnd@...db.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@...db.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@...sr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists