From 011e0db31d1bed8b7f73662be6d57d9f30fa457a Mon Sep 17 00:00:00 2001 From: Deven Desai Date: Wed, 14 Oct 2020 00:53:20 +0000 Subject: [PATCH] Fix for ROCm/HIP breakage - 201013 The following commit seems to have introduced regressions in ROCm/HIP support. https://gitlab.com/libeigen/eigen/-/commit/183a208212353ccf81a664d25dc7660b6269acdd It causes some unit-tests to fail with the following error ``` ... Eigen/src/Core/GenericPacketMath.h:322:3: error: no member named 'bit_and' in the global namespace; did you mean 'std::bit_and'? ... Eigen/src/Core/GenericPacketMath.h:329:3: error: no member named 'bit_or' in the global namespace; did you mean 'std::bit_or'? ... Eigen/src/Core/GenericPacketMath.h:336:3: error: no member named 'bit_xor' in the global namespace; did you mean 'std::bit_xor'? ... ``` The error occurs because, when compiling the device code in HIP/CUDA, the compiler will pick up the some of the std functions (whose calls are prefixed by EIGEN_USING_STD) from the global namespace (i.e. use ::bit_xor instead of std::bit_xor). For this to work, those functions must be declared in the global namespace in the HIP/CUDA header files. The `bit_and`, `bit_or` and `bit_xor` routines are not declared in the HIP header file that contain the decls for the std math functions ( `math_functions.h` ), and this is the cause of the error above. It seems that the newer HIP compilers do support the calling of `std::` math routines within device code, and the ideal fix here would have been to change all calls to std math functions in EIGEN to use the `std::` namespace (instead of the global namespace ), when compiling with HIP compiler. However it seems there was a recent commit to remove the EIGEN_USING_STD_MATH macro and collapse it uses into the EIGEN_USING_STD macro ( https://gitlab.com/libeigen/eigen/-/commit/4091f6b25c5ad0ca3f7c00bd82bfd7ca1bbedee3 ). Replacing all std math calls will essentially require re-surrecting the EIGEN_USING_STD_MATH macro, so not choosing that option. Also HIP compilers only have support std math calls within device code, and not all std functions (specifically not for malloc/free which are prefixed via EIGEN_USING_STD). So modyfing EIGEN_USE_STD implementation to use std:: namspace for HIP will not work either. Hence going for the ugly solution of special casing the three calls that breaking the HIP compile, to explicitly use the std:: namespace --- Eigen/src/Core/GenericPacketMath.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/Eigen/src/Core/GenericPacketMath.h b/Eigen/src/Core/GenericPacketMath.h index db84eb259..fad94535f 100644 --- a/Eigen/src/Core/GenericPacketMath.h +++ b/Eigen/src/Core/GenericPacketMath.h @@ -270,22 +270,34 @@ EIGEN_DEVICE_FUNC inline Packet bitwise_helper(const Packet& a, const Packet& b, /** \internal \returns the bitwise and of \a a and \a b */ template EIGEN_DEVICE_FUNC inline Packet pand(const Packet& a, const Packet& b) { +#if defined(EIGEN_HIP_DEVICE_COMPILE) + return bitwise_helper(a ,b, std::bit_and()); +#else EIGEN_USING_STD(bit_and); return bitwise_helper(a ,b, bit_and()); +#endif } /** \internal \returns the bitwise or of \a a and \a b */ template EIGEN_DEVICE_FUNC inline Packet por(const Packet& a, const Packet& b) { +#if defined(EIGEN_HIP_DEVICE_COMPILE) + return bitwise_helper(a ,b, std::bit_or()); +#else EIGEN_USING_STD(bit_or); return bitwise_helper(a ,b, bit_or()); +#endif } /** \internal \returns the bitwise xor of \a a and \a b */ template EIGEN_DEVICE_FUNC inline Packet pxor(const Packet& a, const Packet& b) { +#if defined(EIGEN_HIP_DEVICE_COMPILE) + return bitwise_helper(a ,b, std::bit_xor()); +#else EIGEN_USING_STD(bit_xor); return bitwise_helper(a ,b, bit_xor()); +#endif } /** \internal \returns the bitwise and of \a a and not \a b */