From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id C6104A053D; Wed, 5 Aug 2020 18:45:13 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2A3FD2C23; Wed, 5 Aug 2020 18:45:13 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 87365A3; Wed, 5 Aug 2020 18:45:11 +0200 (CEST) IronPort-SDR: klPEjnAkYJdv4cqWPQYkEsL3f6x3S7gGT2vuIauYr9l0rY6Z10ZP0ZwhV/MwuoZtPGuXS3JWOz tO0FdBtag41Q== X-IronPort-AV: E=McAfee;i="6000,8403,9704"; a="150347802" X-IronPort-AV: E=Sophos;i="5.75,438,1589266800"; d="scan'208";a="150347802" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Aug 2020 09:45:10 -0700 IronPort-SDR: hSvLYNCyjkxJ3brk6PxCIS37MfkMCq0glCt1KPDTniHzD7zR4o1WQnpC2fivI3VQ9mN4vdybRi jXKyddI3AtvA== X-IronPort-AV: E=Sophos;i="5.75,438,1589266800"; d="scan'208";a="467525008" Received: from bricha3-mobl.ger.corp.intel.com ([10.213.255.148]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 05 Aug 2020 09:45:09 -0700 Date: Wed, 5 Aug 2020 17:45:04 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: dev@dpdk.org, techboard@dpdk.org Message-ID: <20200805164504.GE1716@bricha3-MOBL.ger.corp.intel.com> References: <20200805142141.32337-1-bruce.richardson@intel.com> <2844470.HTv9E7uqEf@thomas> <20200805150741.GD1716@bricha3-MOBL.ger.corp.intel.com> <2902184.3RBbl2PCEx@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2902184.3RBbl2PCEx@thomas> Subject: Re: [dpdk-dev] [dpdk-techboard] [PATCH 1/1] doc: add deprecation notice for CPU build flags X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > > > > --- > > > > --- 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. /Bruce