06/08/2020 23:41, Ferruh Yigit: > On 8/5/2020 5:45 PM, Bruce Richardson wrote: > > On Wed, Aug 05, 2020 at 05:15:31PM +0200, Thomas Monjalon wrote: > >> 05/08/2020 17:07, Bruce Richardson: > >>> On Wed, Aug 05, 2020 at 04:57:42PM +0200, Thomas Monjalon wrote: > >>>> 05/08/2020 16:21, Bruce Richardson: > >>>>> The RTE_MACHINE_CPUFLAGS_* macros in DPDK build just duplicate info from > >>>>> the compiler macros, so we can remove them and just use the compiler > >>>>> versions directly. > >>>>> > >>>>> Signed-off-by: Bruce Richardson <bruce.richard...@intel.com> > >>>>> --- > >>>>> --- a/doc/guides/rel_notes/deprecation.rst > >>>>> +++ b/doc/guides/rel_notes/deprecation.rst > >>>>> +* build macros: The macros defining RTE_MACHINE_CPUFLAG_* will be > >>>>> removed > >>>>> + from the build. The information provided by these macros is available > >>>>> + through standard compiler macros. For example, > >>>>> RTE_MACHINE_CPUFLAG_SSE3 > >>>>> + duplicates the compiler-provided macro __SSE3__. > >>>> > >>>> I see 2 advantages of having alias: > >>>> - if 2 compilers differ, we can manage > >>>> - we can find all such macros with grep RTE_MACHINE_CPUFLAG > >>>> > >>> > >>> Sure, if you think it's worthwhile keeping them, we can do so. It's just > >>> right now they seem to be largely a waste of space. For #2, I'm not sure > >>> when we would want to grep for them all, except possibly to remove them. > >>> :-) > >> > >> For instance, in a lib, I grep where we have CPU specific code. > >> > >> We probably need more opinions, I can change my mind. > >> > > Yes, we need some more opinions here. > > > > For the above point, yes it's useful to be able to grep for these things, > > but it does assume that everybody uses the DPDK-defines and doesn't use the > > compiler ones directly. There are a few instances where there seems to be > > x86, ARM or PPC compiler flags already directly used in the code. > > > > As well as brevity, the other big reason I see for removing them is to > > avoid having to maintain these lists of flags for future use. Right now, > > with -march=skylake-avx512, gcc will define 7 different AVX feature flags. > > DPDK, on the other hand, only provides equivalent defines for 3 of them. > > We have no automatic way of pulling all newly added flags from gcc/clang > > into our build, so we just add them on an as-needed basis, which makes it > > more awkward for those adding new features that may depend on the flags. If > > we always try to add in all flags to keep things in sync, we are just > > duplicating the efforts the compiler authors have already done for us, and > > wasting the effort for those flags that are unused. > > > > Sounds reasonable, > > Acked-by: Ferruh Yigit <ferruh.yi...@intel.com>
Applied
