On Fri, Apr 1, 2016 at 12:13 PM, Otavio Salvador <otavio.salva...@ossystems.com.br> wrote: > 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.
I think the last comment from Richard was: "I'm planning to drop the patch triggering this from -next and defer it until 2.2. The discussions can happen in the meantime to get a patchset we're all happy with." So I don't think anything is expected for 2.1. The floor is still open for discussion for 2.2. One initial question seems to be whether we're aiming for a point solution for armv8a or a wider ranging cleanup? > -- > 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
