<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <div class="moz-cite-prefix"> <div class="moz-cite-prefix">Considering this problem further, I don't see a way to avoid the CLANG compiler error with a function implementation. We would need a macro implementation similar to CLANGS arm_neon.h. In addition, it may be necessary to provide separate implementations for CLANG and non-CLANG compilers since the builtins between the toolchains are different. One way to address this would be keep the existing function implementation, and add a new macro implementation for CLANG. </div> <div class="moz-cite-prefix"> </div> <div class="moz-cite-prefix">For example, something like:</div> <div class="moz-cite-prefix"> </div> <div class="moz-cite-prefix"> <blockquote>#if !defined(RTE_CC_CLANG) #if (defined(RTE_ARCH_ARM) && defined(RTE_ARCH_32)) || \ (defined(RTE_ARCH_ARM64) && RTE_CC_IS_GNU && (GCC_VERSION < 70000)) /* NEON intrinsic vcopyq_laneq_u32() is not supported in ARMv7-A(AArch32) * On AArch64, this intrinsic is supported since GCC version 7. */ static inline uint32x4_t vcopyq_laneq_u32(uint32x4_t a, const int lane_a, uint32x4_t b, const int lane_b) { return vsetq_lane_u32(vgetq_lane_u32(b, lane_b), a, lane_a); } #endif #else #if defined(RTE_ARCH_ARM) && defined(RTE_ARCH_32) /* NEON intrinsic vcopyq_laneq_u32() is not supported in ARMv7-A(AArch32) * On AArch64, this intrinsic is supported */ #ifdef LITTLE_ENDIAN #define vcopyq_laneq_u32(__arg1, __arg2, __arg3, __arg4) __extension__ ({ \ uint32x4_t __ret; \ uint32x4_t __lcl_arg1 = __arg1; \ uint32x4_t __lcl_arg3 = __arg3; \ __ret = vsetq_lane_u32(vgetq_lane_u32(__lcl_arg3, __arg4), __lcl_arg1, __arg2); \ __ret; \ }) #else #define __noswap_vsetq_lane_u32(__arg1, __arg2, __arg3) __extension__ ({ \ uint32x4_t __ret; \ uint32_t __lcl_arg1 = __arg1; \ uint32x4_t __lcl_arg2 = __arg2; \ __ret = (uint32x4_t) __builtin_neon_vsetq_lane_i32(__lcl_arg1, (int32x4_t)__lcl_arg2, __arg3); \ __ret; \ }) #define __noswap_vgetq_lane_u32(__arg1, __arg2) __extension__ ({ \ uint32_t __ret; \ uint32x4_t __lcl_arg1 = __arg1; \ __ret = (uint32_t) __builtin_neon_vgetq_lane_i32((int32x4_t)__lcl_arg1, __arg2); \ __ret; \ }) #define vcopyq_laneq_u32(__arg1, __arg2, __arg3, __arg4) __extension__ ({ \ uint32x4_t __ret; \ uint32x4_t __lcl_arg1 = __arg1; \ uint32x4_t __lcl_arg3 = __arg3; \ uint32x4_t __rev1; \ uint32x4_t __rev3; \ __rev1 = __builtin_shufflevector(__lcl_arg1, __lcl_arg1, 3, 2, 1, 0); \ __rev3 = __builtin_shufflevector(__lcl_arg3, __lcl_arg3, 3, 2, 1, 0); \ __ret = __noswap_vsetq_lane_u32(__noswap_vgetq_lane_u32(__rev3, __arg4), __rev1, __arg2); \ __ret = __builtin_shufflevector(__ret, __ret, 3, 2, 1, 0); \ __ret; \ }) #endif #endif #endif </blockquote> </div> <div class="moz-cite-prefix"> </div> <div class="moz-cite-prefix">NOTE1: I saw no reason the CLANG arm_neon.h AARCH64 macros would not work for AARCH32, so the macros in this sample implementation are copies CLANG originals modified for (my) readability. I'm not an attorney, but if used, it may be necessary to include the banner from the CLANG arm_neon.h. NOTE2: While I can build the CLANG ARM implementation, I lack the hardware to test it. </div> <div class="moz-cite-prefix"> </div> <div class="moz-cite-prefix">Regards,</div> <div class="moz-cite-prefix">Roger</div> <div class="moz-cite-prefix"> </div> </div> <div class="moz-cite-prefix">On 12/3/24 7:37 PM, Roger Melton (rmelton) wrote: </div> <blockquote type="cite" cite="mid:0da20131-67d8-4012-ba00-d777bf50a1f1@cisco.com"> <div class="moz-cite-prefix">After looking at this a bit closer today, I realize that my assertion that CLANG14 does support vcopyq_laneq_u32() for 32bit ARM was incorrect. It does not. The reason that disabling the implementation in rte_vect.h works for our clang builds is that we do not build the l3fwd app nor the ixgbe PMD for our application, and they are the only libraries that reference that function.</div> <div class="moz-cite-prefix"> </div> <div class="moz-cite-prefix">The clang compile errors appear to be related to how clang handles compile time constants, but I'm am again unsure how to resolve them in a way that would work for both GNU and clang.</div> <div class="moz-cite-prefix"> </div> <div class="moz-cite-prefix">Any suggestions? </div> <div class="moz-cite-prefix"> </div> <div class="moz-cite-prefix">Regards,</div> <div class="moz-cite-prefix">Roger</div> <div class="moz-cite-prefix"> </div> <div class="moz-cite-prefix"> </div> <div class="moz-cite-prefix">On 12/2/24 8:26 PM, Ruifeng Wang wrote: </div> <blockquote type="cite" cite="mid:AS8PR08MB708004C682011D52122CE4D69E362@AS8PR08MB7080.eurprd08.prod.outlook.com"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style>@font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face {font-family:DengXian; panose-1:2 1 6 0 3 1 1 1 1 1;}@font-face {font-family:Aptos; panose-1:2 11 0 4 2 2 2 2 2 4;}@font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;}@font-face {font-family:"\@DengXian"; panose-1:2 1 6 0 3 1 1 1 1 1;}p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:10.0pt; font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;}pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0cm; font-size:10.0pt; font-family:"Courier New";}span.cp {mso-style-name:cp;}span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:"Consolas",serif;}span.cm {mso-style-name:cm;}span.k {mso-style-name:k;}span.w {mso-style-name:w;}span.kr {mso-style-name:kr;}span.n {mso-style-name:n;}span.nf {mso-style-name:nf;}span.p {mso-style-name:p;}span.kt {mso-style-name:kt;}span.EmailStyle30 {mso-style-type:personal-reply; font-family:"Aptos",sans-serif; color:windowtext;}.MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;}div.WordSection1 {page:WordSection1;}</style> <div class="WordSection1"> +Arm folks.<o:p></o:p> <o:p> </o:p> <div id="mail-editor-reference-message-container"> <div> <div> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: Roger Melton (rmelton) <a class="moz-txt-link-rfc2396E" href="mailto:rmelton@cisco.com" moz-do-not-send="true"> <rmelton@cisco.com></a> Date: Tuesday, December 3, 2024 at 3:39 AM To: <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:dev@dpdk.org" moz-do-not-send="true">dev@dpdk.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:dev@dpdk.org" moz-do-not-send="true"> <dev@dpdk.org></a>, Ruifeng Wang <a class="moz-txt-link-rfc2396E" href="mailto:Ruifeng.Wang@arm.com" moz-do-not-send="true"> <Ruifeng.Wang@arm.com></a> Subject: lib/eal/arm/include/rte_vect.h fails to compile with clang14 for 32bit ARM<o:p></o:p> </div> Hey folks,<o:p></o:p> We are building DPDK with clang14 for a 32bit armv8-a based CPU and ran into a compile error with the following from lib/eal/arm/include/rte_vect.h:<o:p></o:p> <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> <pre>#if (defined(RTE_ARCH_ARM) && defined(RTE_ARCH_32)) || \<o:p></o:p></pre> <pre>(defined(RTE_ARCH_ARM64) && <a href="https://elixir.bootlin.com/dpdk/v24.11/C/ident/RTE_CC_IS_GNU" moz-do-not-send="true">RTE_CC_IS_GNU</a> && (<a href="https://elixir.bootlin.com/dpdk/v24.11/C/ident/GCC_VERSION" moz-do-not-send="true">GCC_VERSION</a> < 70000))<o:p></o:p></pre> <pre>/* NEON intrinsic vcopyq_laneq_u32() is not supported in ARMv7-A(AArch32)<o:p></o:p></pre> <pre> * On AArch64, this intrinsic is supported since GCC version 7.<o:p></o:p></pre> <pre> */<o:p></o:p></pre> <pre>static inline uint32x4_t<o:p></o:p></pre> <pre><a href="https://elixir.bootlin.com/dpdk/v24.11/C/ident/vcopyq_laneq_u32" moz-do-not-send="true">vcopyq_laneq_u32</a>(uint32x4_t a, const int lane_a,<o:p></o:p></pre> <pre> uint32x4_t b, const int lane_b)<o:p></o:p></pre> <pre>{<o:p></o:p></pre> <pre> return vsetq_lane_u32(vgetq_lane_u32(b, lane_b), a, lane_a);<o:p></o:p></pre> <pre>}<o:p></o:p></pre> <pre>#endif<o:p></o:p></pre> </blockquote> clang14 compile fails as follows: <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> In file included from ../../../../../../cisco-dpdk-upstream-arm-clang-fixes.git/lib/eal/common/eal_common_options.c:36: ../../../../../../cisco-dpdk-upstream-arm-clang-fixes.git/lib/eal/arm/include/rte_vect.h:80:24: error: argument to '__builtin_neon_vgetq_lane_i32' must be a constant integer return vsetq_lane_u32(vgetq_lane_u32(b, lane_b), a, lane_a); ^ ~~~~~~ /auto/binos-tools/llvm14/llvm-14.0-p24/lib/clang/14.0.5/include/arm_neon.h:7697:22: note: expanded from macro 'vgetq_lane_u32' __ret = (uint32_t) __builtin_neon_vgetq_lane_i32((int32x4_t)__s0, __p1); \ ^ ~~~~ /auto/binos-tools/llvm14/llvm-14.0-p24/lib/clang/14.0.5/include/arm_neon.h:24148:19: note: expanded from macro 'vsetq_lane_u32' uint32_t __s0 = __p0; \ ^~~~ In file included from ../../../../../../cisco-dpdk-upstream-arm-clang-fixes.git/lib/eal/common/eal_common_options.c:36: ../../../../../../cisco-dpdk-upstream-arm-clang-fixes.git/lib/eal/arm/include/rte_vect.h:80:9: error: argument to '__builtin_neon_vsetq_lane_i32' must be a constant integer return vsetq_lane_u32(vgetq_lane_u32(b, lane_b), a, lane_a); ^ ~~~~~~ /auto/binos-tools/llvm14/llvm-14.0-p24/lib/clang/14.0.5/include/arm_neon.h:24150:24: note: expanded from macro 'vsetq_lane_u32' __ret = (uint32x4_t) __builtin_neon_vsetq_lane_i32(__s0, (int32x4_t)__s1, __p2); \ ^ ~~~~ 2 errors generated.<o:p></o:p> </blockquote> <o:p> </o:p> clang14 does appear to support the vcopyq_laneq_u32() intrinsic, s0 we want to skip the conditional implementation.<o:p></o:p> Two approaches I have tested to resolve the error are:<o:p></o:p> 1) skip if building with clang:<o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> #if !defined(__clang__) && ((defined(RTE_ARCH_ARM) && defined(RTE_ARCH_32)) || \ 72 (defined(RTE_ARCH_ARM64) && RTE_CC_IS_GNU && (GCC_VERSION < 70000))) <o:p></o:p> </blockquote> 2) skip if not building for ARMv7: <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> #if (defined(RTE_ARCH_ARMv7) && defined(RTE_ARCH_32)) || \ (defined(RTE_ARCH_ARM64) && RTE_CC_IS_GNU && (GCC_VERSION < 70000)) <o:p></o:p> </blockquote> Both address our immediate problem, but may not be a appropriate for all cases.<o:p></o:p> Can anyone suggest the proper way to address this? I'll be submitting an patch once I have a solution that is acceptable to the community.<o:p></o:p> Regards, Roger <o:p></o:p> <o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p></o:p> </div> </div> </div> </div> </blockquote> </blockquote> </body> </html>