From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id D89EEA0032; Tue, 21 Jun 2022 11:31:09 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CC040427EE; Tue, 21 Jun 2022 11:31:09 +0200 (CEST) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by mails.dpdk.org (Postfix) with ESMTP id BB73C4069C for ; Tue, 21 Jun 2022 11:31:08 +0200 (CEST) Received: by mail-lf1-f43.google.com with SMTP id a2so21354077lfg.5 for ; Tue, 21 Jun 2022 02:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/khBAFbibEGQl6cL7oYRLGP6zaJp0/JrZnrYNmMsFns=; b=Sv5KeCNOg/2UoRjPmGeh645gWSVyFyL4D/CV3+ZeHDSn5ZpTlqoLLXkcuSpkZHiH78 WQlIg5cWdAxxWMWzR/i++DTJq+QVrTneWgwUs7XhYfc69z1Lhvi3J5SMekF1H2UhRsCt +UGySqvI/8qqlC/NX9xZqiOQf+fGT/iTZNAa0p+6iEQ2mXX8Ppc6K5trIC1InXjlxUxO FatkFPcXMO6r/ci2MUVyLnzR80JxhTATAO1+WGKoP38vMIy7kZZKCFttJQvNDyYgrVCE edQlZYdf+jjV8bfwyyP2knCnTrvHITufaeO7yT1AcGDSeBlC0hEF45gJ5NayWQXrDKaL BNEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/khBAFbibEGQl6cL7oYRLGP6zaJp0/JrZnrYNmMsFns=; b=Yl6v3yYTw82CL7bSeS0uafsVLhoTJ0PLFYqp0yOjZha8oDKe5RtcId7VWXgHik868E BmdfC3TBv/Nx04vIJcLCFBOO5Y4wZ8radavkIp/FY4KEWaXwodLuQJamhmhoMfm0+Njp ayw2fiGQ4jjL4t+bQawZZjxGS86c5+v9YTJApaqbDuiF3lh9IOO75r2xY7QjYWZf9unM /Eq2YIQxYPhAEM6fAeBH1UruKpWXaZDzt64dv/JrZfb5ro9bUnwlJnok3mvZmMuQAmUx p4jujLpUvj6wrzyz78/VErpRY4cSsUCy2ZnPLvp+72cbY4fwRBOLINSOiVHR2teR0+qv prQg== X-Gm-Message-State: AJIora8JilQbGJzTYkptvasFqnz2p2cwaq0H7b531FzegoHHKbjgHMGl R0MezAuY703bK2LR9gCM29M5oXIQCuj6irFX+qr1mw== X-Google-Smtp-Source: AGRyM1tclvz9Jmd73P1Haad4hINy+XfMaS8wZaZMtYJFx0/aBR5FgqbBu5LsE+U6nF7LxR4itUn7YzhCdm2fqGCuu4M= X-Received: by 2002:a05:6512:3d8c:b0:479:51be:727f with SMTP id k12-20020a0565123d8c00b0047951be727fmr16326295lfv.289.1655803868327; Tue, 21 Jun 2022 02:31:08 -0700 (PDT) MIME-Version: 1.0 References: <20220609121701.716299-1-kda@semihalf.com> <63ed6e6c-337d-8f8a-9410-1e43b0561967@linux.vnet.ibm.com> In-Reply-To: <63ed6e6c-337d-8f8a-9410-1e43b0561967@linux.vnet.ibm.com> From: =?UTF-8?Q?Stanis=C5=82aw_Kardach?= Date: Tue, 21 Jun 2022 11:30:32 +0200 Message-ID: Subject: Re: [PATCH 0/3] Fix xmm_t to rte_xmm_t scalar conversion To: David Christensen Cc: David Marchand , dev , upstream@semihalf.com, Aaron Conole , Bruce Richardson , "Ananyev, Konstantin" , "Ruifeng Wang (Arm Technology China)" , Jerin Jacob Kollanukkaran Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Tue, Jun 21, 2022 at 12:54 AM David Christensen wrote: > > > On Thu, Jun 9, 2022 at 2:17 PM Stanislaw Kardach wro= te: > >> > >> As David noticed in [1] there is an issue with C++ compilation of the > >> rte_vect.h header in RISC-V. Upon closer inspection, the problem appea= rs on > >> all architectures due to the type conversion rules in C++. > >> More precisely a union type rte_xmm_t requires a conversion constructo= r > >> from xmm_t type. > >> The most obvious fix is to use a structure initializer for such copies > >> (since rte_xmm_t union contains xmm_t anyway). The generated assembly > >> at -O2 is exactly the same, so there's no real impact. > >> > >> The bigger question is whether accessing bits of the architecture spec= ific > >> xmm_t type in an array fashion is always correct? All current architec= tures > >> define rte_xmm_t in the same manner implying that. > > > > Copying other arch maintainers. > > My read of the Altivec vector layout for LE systems says the existing > union operator rte_xmm_t is correct, though my C++ experience is > limited. How can I generate an error with C++ to expose this issue? > > Dave To replicate this issue: 1. Apply the patch below. In essence it forces the use of scalar lpm and changes C++ compiler to g++ so that meson properly detects it. Otherwise C++ checks won't be generated. 2. Configure build with: meson build-ppc64le --werror --cross-file config/ppc/ppc64le-power8-linux-gcc-ubuntu -Dcheck_includes=3Dtrue 3. Build with: ninja -C build-ppc64le buildtools/chkincs/chkincs-cpp Note that the build target only gets generated if C++ compiler is properly discovered by meson. To be honest I'm not sure why powerpc64le-linux-gnu-cpp doesn't get properly picked up by meson. Also of interesting note the similar substitution should be made for arm64 but it seems like a separate thread. Patch for issue replication: diff --git a/config/arm/arm64_armv8_linux_gcc b/config/arm/arm64_armv8_linu= x_gcc index 5391d35389..5c32f6b9ca 100644 --- a/config/arm/arm64_armv8_linux_gcc +++ b/config/arm/arm64_armv8_linux_gcc @@ -1,6 +1,6 @@ [binaries] c =3D 'aarch64-linux-gnu-gcc' -cpp =3D 'aarch64-linux-gnu-cpp' +cpp =3D 'aarch64-linux-gnu-g++' ar =3D 'aarch64-linux-gnu-gcc-ar' strip =3D 'aarch64-linux-gnu-strip' pkgconfig =3D 'aarch64-linux-gnu-pkg-config' diff --git a/config/ppc/ppc64le-power8-linux-gcc-ubuntu b/config/ppc/ppc64le-power8-linux-gcc-ubuntu index 803c612cbc..2e6b13a406 100644 --- a/config/ppc/ppc64le-power8-linux-gcc-ubuntu +++ b/config/ppc/ppc64le-power8-linux-gcc-ubuntu @@ -1,6 +1,6 @@ [binaries] c =3D 'powerpc64le-linux-gnu-gcc' -cpp =3D 'powerpc64le-linux-gnu-cpp' +cpp =3D 'powerpc64le-linux-gnu-g++' ar =3D 'powerpc64le-linux-gnu-ar' strip =3D 'powerpc64le-linux-gnu-strip' diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h index 4f38864fde..fd1362a027 100644 --- a/lib/lpm/rte_lpm.h +++ b/lib/lpm/rte_lpm.h @@ -397,19 +397,7 @@ static inline void rte_lpm_lookupx4(const struct rte_lpm *lpm, xmm_t ip, uint32_t hop[4], uint32_t defv); -#if defined(RTE_ARCH_ARM) -#ifdef RTE_HAS_SVE_ACLE -#include "rte_lpm_sve.h" -#else -#include "rte_lpm_neon.h" -#endif -#elif defined(RTE_ARCH_PPC_64) -#include "rte_lpm_altivec.h" -#elif defined(RTE_ARCH_X86) -#include "rte_lpm_sse.h" -#else #include "rte_lpm_scalar.h" -#endif #ifdef __cplusplus } --=20 Best Regards, Stanis=C5=82aw Kardach