On Tue, Jun 12, 2018 at 2:43 PM, Mark Hatle <mark.ha...@windriver.com> wrote: > On 6/12/18 3:39 PM, Andre McCurdy wrote: >> On Tue, Jun 12, 2018 at 1:00 PM, Mark Hatle <mark.ha...@windriver.com> wrote: >>> On 6/12/18 10:49 AM, Herve Jourdain wrote: >>>> Hi, >>>> >>>> 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', >>>> '+nofp' >>>> 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 >>> don't >>> 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 >>> has >>> 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 >>> present. >> >> It's not _always_ present - it's missing for armv4 CPUs such as StrongARM. > > Always present on -modern- ARM processors.. ARMv7 (Cortex) and newer AFAIK. > I'm > not referring to older cores.
OK. Thanks for clarifying. >> However the option has been unnecessarily propagated into tuning files >> for higher architecture levels where support for Thumb _is_ always >> present. >> > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
