Erik, does Artem's suggestion work for you? On Wed, Jun 19, 2019 at 2:52 PM Artem Belevich <[email protected]> wrote:
> > > On Wed, Jun 19, 2019 at 1:47 PM Rasmus Munk Larsen <[email protected]> > wrote: > >> It looks like we broke the Eigen Cuda build on Mac. What do you think >> about his workaround? >> >> ---------- Forwarded message --------- >> From: Eric Klein <[email protected]> >> Date: Wed, Jun 19, 2019 at 1:39 PM >> Subject: [eigen] Mac CUDA build failure question >> To: <[email protected]> >> >> >> Hello all, >> >> I posted a question on the forums several days back, but suspect that >> might not be the right place to be asking what I'm asking, so I'm trying >> the mailing list as well. >> >> I'll just repost here what I put in the forums, but the link to that is >> here: https://forum.kde.org/viewtopic.php?f=74&t=161199 >> >> I'm trying to build Eigen on Mac for CUDA (using the nvcc compiler), and >> getting build errors. I understand the errors, and I have a change that >> lets me dodge the build failures, but I suspect it's not the right change >> for checkin, and so I'm looking for feedback. >> >> So the issue I have is in Half.h. I wind up getting errors about a bunch >> of operators being already defined. The core issue is that on Mac, nvcc >> (the CUDA compliler) is using gcc as the host compiler, but gcc on Mac is >> built on top of clang. Eigen seems to be implicitly assuming that the >> presence of clang implies that absence of CUDA (or at least the absence of >> nvcc CUDA support). >> >> In my build I'm hitting this block: >> >> #if (defined(EIGEN_HAS_CUDA_FP16) && defined(EIGEN_CUDA_ARCH) && \ >> EIGEN_CUDA_ARCH >= 530) || \ >> (defined(EIGEN_HAS_HIP_FP16) && defined(HIP_DEVICE_COMPILE)) >> #define EIGEN_HAS_NATIVE_FP16 >> #endif >> >> which results in EIGEN_HAS_NATIVE_FP16 being set, and so we wind up >> compiling in all the operators from Half.h:253-313. That's fine so far. >> > > This assumes device-side compilation. > > >> >> What happens next is we hit this line: >> >> #if !defined(EIGEN_HAS_NATIVE_FP16) || EIGEN_COMP_CLANG // Emulate >> support for half floats >> >> which is followed shortly after by (roughly) the same operator functions >> (but... emulated), and I get errors because those operator functions were >> defined above. >> > > If Clang were CUDA compiler, that would not be a problem. This implies > that it's a CUDA compilation with NVCC. What puzzles me is how did we end > up with EIGEN_COMP_CLANG defined for the *device* side of the > compilation. I suspect it's the side effect of NVCC doing device-side > preprocessing with clang, but actually compiling with cicc, which is > obviously not clang. > > I guess what we need to do here is something like this: > #if !defined(EIGEN_HAS_NATIVE_FP16) || (EIGEN_COMP_CLANG && ! > EIGEN_COMP_NVCC) > > That, and a comment explaining what's going on. > > If that does not help, it would be great to compile with '-keep -verbose' > and check which compilation phase is failing and what exactly is it trying > to compile. > > --Artem > > >> So. My hack to work around this is to ensure that EIGEN_COMP_CLANG gets >> set to 0 in Macros.h if __NVCC__ is defined. That works fine for me >> locally, and gets Eigen building fine (and thus unblocks me on getting >> TensorFlow building for Mac, or at least unblocks this issue). >> >> I'm willing to bet however that this is the wrong thing to do in general. >> I don't understand enough of what this second code block is doing to really >> understand why clang is being treated differently than nvcc here (and >> specifically why half support needs to be emulated in the presence of >> clang). I believe there is a version of clang that supports CUDA (at least >> on some platforms?). Presumably this is for that, but I don't know enough >> about how that differs from nvcc to fully grok this. >> >> Can anyone help enlighten me about the best way to fix this? >> >> Thanks! >> --- >> Eric Klein >> [email protected] >> > > > -- > --Artem Belevich >
