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. > 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
