> On Apr 1, 2016, at 3:03 PM, Andre McCurdy <armccu...@gmail.com> wrote: > > 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?
I would support the latter. Andre, since you have mentioned it earlier would you mind opening a bugzilla entry for cleanup for 2.2 ?
signature.asc
Description: Message signed with OpenPGP using GPGMail
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
