From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 24108C433E2 for ; Thu, 3 Sep 2020 09:48:42 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id BC15020709 for ; Thu, 3 Sep 2020 09:48:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BC15020709 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 503C61BEAF; Thu, 3 Sep 2020 11:48:40 +0200 (CEST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id BACF3E07 for ; Thu, 3 Sep 2020 11:48:38 +0200 (CEST) IronPort-SDR: n/oqPkCTWzmGk6I3nzUBWjX5/BhaPujWdRJlrbCk5zljcZB81T+eRcG9xmToKsEcUEPsp9cKzO y+KLDCjYPKwg== X-IronPort-AV: E=McAfee;i="6000,8403,9732"; a="175600306" X-IronPort-AV: E=Sophos;i="5.76,386,1592895600"; d="scan'208";a="175600306" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Sep 2020 02:48:37 -0700 IronPort-SDR: sVHpMtsk4Ekoaa9TY09Xl5/ti2hBo4RE/3uSMeqlnLUOGNG1kOJaTXe+/gqxkrtQe3+FcsuyGX 8MQgDx+mS7gw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,386,1592895600"; d="scan'208";a="326154453" Received: from rnicolau-mobl1.ger.corp.intel.com (HELO [10.251.95.229]) ([10.251.95.229]) by fmsmga004.fm.intel.com with ESMTP; 03 Sep 2020 02:48:35 -0700 To: David Christensen , dev@dpdk.org Cc: thomas@monjalon.net, david.marchand@redhat.com, viktorin@rehivetech.com, ruifeng.wang@arm.com, jerinj@marvell.com, bruce.richardson@intel.com, konstantin.ananyev@intel.com References: <20200902104343.31774-1-radu.nicolau@intel.com> From: "Nicolau, Radu" Message-ID: <3da14380-51dc-5bb0-05fb-1d71162ecd08@intel.com> Date: Thu, 3 Sep 2020 10:48:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Subject: Re: [dpdk-dev] [PATCH v1 0/4] Remove RTE_MACHINE_CPUFLAG_ macros 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 9/2/2020 5:57 PM, David Christensen wrote: > On 9/2/20 3:43 AM, Radu Nicolau wrote: >> Remove RTE_MACHINE_CPUFLAG_ macros from the build. >> Deprecation notice sent, pasted here for reference: >> >>    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__. >> >> Radu Nicolau (4): >>    x86: change cpuflag macros to compiler macros >>    arm: change cpuflag macros to compiler macros >>    ppc: change cpuflag macros to compiler macros >>    doc: remove reference to RTE_MACHINE_CPUFLAG > > I'm not too familiar with clang and icc.  Do all compilers use the > same macro definitions for the same CPU features?  I would have > thought the RTE_* definitions were there because there are compiler or > compiler version differences that need to be supported. > > Dave All supported compilers should have these defines, and the RTE_MACHINE_CPU macros were defined based on the compiler defined macros, as an unnecessary extra step. Furthermore, as per Bruce's comment, new features will be easily implemented directly in the relevant sections without needing to update the build system.