Hello folks, On Wed, Mar 30, 2016 at 8:59 PM, Andre McCurdy <armccu...@gmail.com> wrote: > On Wed, Mar 30, 2016 at 3:46 PM, Phil Blundell <p...@pbcl.net> wrote: >> On Wed, 2016-03-30 at 11:53 -0700, Andre McCurdy wrote: >>> Either way it shouldn't be a concern for the CPU tuning files. >>> Building Thumb2 for an armv8a CPU is really just an extension of >>> "optimise for size" and we don't include -Os, -O2, etc options in the >>> CPU tuning files. >> >> Yes, agreed. In principle there's no reason that the compiler couldn't >> choose between A32 and T32 instruction sets dynamically for each >> compilation unit (or each function) according to which it thinks would >> give the better result. And from the user's point of view, the outcome >> should be equivalent apart from minor performance differences. >> >>> >> For most cores from Cortex A9 onwards NEON and VFP are optional, so >>> >> hardcoded assumptions won't work. >> >>> Nothing very concrete. The ARM Cortex-A Series Programmer’s Guide for >>> ARMv8-A mentions: >>> >>> "Both floating-point and NEON are required in all standard ARMv8 >>> implementations. However, implementations targeting specialized >>> markets may support the following combinations: >>> >>> - No NEON or floating-point. >>> - Full floating-point and SIMD support with exception trapping. >>> - Full floating-point and SIMD support without exception trapping. >> >> Is there any evidence that anyone is actually building ARMv8-A (as >> opposed to -R or -M) cores that lack VFP and/or NEON? Unless there is a >> fairly clear indication that such cores do exist and are likely to be >> used with OE, I think we should not complicate the tuning files with >> support for such things. Anybody who wants them can always add >> appropriate tunes later, either in oe-core or in their own layer. > > I can't find any evidence of real ARMv8-A cores without NEON or VFP, > so if any "new approach" to ARM CPU tuning files is limited to armv8a > then hardcoding support for NEON and VFP is probably going to work out > OK (at least until someone wants support for the half-precision > floating point extensions added in ARMv8.2-A). > > Personally though, I'd like to see a comprehensive cleanup and > restructuring which could be applied to all ARM tuning files, > including armv7a where NEON certainly is optional in the real world.
Could you, Phil and Khem summarize the remarks in a succinct way? To be honest I am a little lost on what changes you all are expecting on top of the last patch version. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
