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