On Tue, Jun 12, 2018 at 4:32 PM, Herve Jourdain <herve.jourd...@neuf.fr> wrote:
> Hi Andre,
> I believe I did say always present on armv8 and armv7, I did not mean before
Right. The point of considering older architecture levels was that IF
we were to drop support for armv4 (I'm not necessarily suggesting that
we do) then we could simplify the tuning files quite a lot, since then
every supported ARM core would support Thumb.
> Having separate tunes for thumb support was necessary on previous
> architectures where it was optional, but it persisted for architectures which
> made thumb mandatory.
> I’m not even advocating removing the tune option for previous architectures
> that would normally not require it, but I believe we should get rid of it for
> new ARM architectures.
We all seem to be strongly agreeing with each other :-)
BTW, I don't know how much history you've aware of from when this
topic has been discussed previously on the list (it's come up a few
times...). There are people who've created distros etc which do
actually rely on being able to define (for example) an armv7a machine
without Thumb support, even though such a thing doesn't actually
exist. So, as much as we might all agree that removing the option to
disable Thumb support for armv7a etc might be "the right thing to do",
in practice there are going to be people who object to it.
>> On 13 Jun 2018, at 04:39, Andre McCurdy <armccu...@gmail.com> wrote:
>>> On Tue, Jun 12, 2018 at 1:00 PM, Mark Hatle <mark.ha...@windriver.com>
>>>> On 6/12/18 10:49 AM, Herve Jourdain wrote:
>>>> So I agree with you about restricting to what gcc can support, that's
>>>> actually my proposal (actually, probably a subset of what gcc can support).
>>>> So for armv8, gcc supports, as architectures: armv8-a, armv8.1-a,
>>>> armv8.2-a, armv8.3-a, armv8.4-a.
>>>> Then, you can add the supported options with a "+" after the architecture.
>>>> Options supported for armv8-a are: '+crc', '+simd', '+crypto',
>>>> '+nocrypto', '+nofp'
>>>> Options supported for armv8.1-a are: '+simd', '+crypto', '+nocrypto',
>>>> Options supported for armv8.2-a and armv8.3-a are: '+fp16', '+fp16fml',
>>>> '+simd', '+crypto', '+dotprod', '+nocrypto', '+nofp'
>>>> Options supported for armv8.4-a are: '+fp16', '+simd', '+crypto',
>>>> '+dotprod', '+nocrypto', '+nofp'
>>>> As you can see, proposals for armv8-a, whether my previous one, the new
>>>> one here, or even the one I have updated and used in production, just
>>>> capture the existing complexity, and not add to it.
>>>> and support for armv8.1-a, armv8.2-a, armv8.3-a, armv8.4a will only add
>>>> more options down the line.
>>> Sounds a lot like the above would be TUNE_FEATURES to me.. (even if we
>>> necessarily define a tune that uses them -- if it's standard another layer
>>> certainly could.)
>>>> Regarding fpu, gcc supports the following for armv8: fp-armv8,
>>>> neon-fp-armv8, and crypto-neon-fp-armv8.
>>>> Regarding cpu, I believe that the armv8 supported ones are: ‘cortex-a32’,
>>>> ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, ‘cortex-a57’, ‘cortex-a72’,
>>>> ‘cortex-a73’, ‘cortex-a75’.
>>>> I personally would like to keep tuning for a specific CPU as much as
>>>> possible (again I'm working closely with various ARM-based SoCs, so my
>>>> opinion might be tainted).
>>> Thats a lot of options, but if we focus on TUNE_FEATURES, I think it's a bit
>>> more reasonable to support all of this.. (maybe that is what needs to be
>>> done in
>>> the future as well for other architectures.. focus on the 'gcc' behavior and
>>> generate TUNE_FEATURES matching the compiler.)
>>> I'd like Khem's opinion on how crazy of an idea that is.
>>>> One thing that could be done to simplify things would be to just use the
>>>> cpu, and add the options to it. Gcc supports adding options to the cpu.
>>>> '+nofp' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’ and ‘cortex-a55’
>>>> '+crypto' for ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’,
>>>> ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’
>>>> That could simplify the tune settings, but would give less control than
>>>> what we currently have.
>>>> As you might have guessed, I do put a specific emphasis on the crypto
>>>> option, and on the neon option, which are the most interesting for armv8
>>>> in my opinion.
>>> In the past 'crypto' options have only been assembly.. if that's changed it
>>> definitely opened up a new facet in all of this work.
>>>> Regarding thumb, always adding it to the tune without creating specific
>>>> variants with or without thumb makes sense, since the tune is normally
>>>> about the SoC capabilities, and arv7 and armv8 both support it.
>>>> You can always select whether you want thumb or not by setting
>>>> ARM_INSTRUCTION_SET appropriately at the distro level.
>>> Yes, that might be needed now that thumb is theoretically always supposed
>>> to be
>> It's not _always_ present - it's missing for armv4 CPUs such as StrongARM.
>> However the option has been unnecessarily propagated into tuning files
>> for higher architecture levels where support for Thumb _is_ always
Openembedded-core mailing list