tambre added a comment. > Magically changing compiler target based on something external to compiler is > a bad idea IMO. I would expect a compilation with exactly the same compiler > options to do exactly the same thing. If we magically change default target, > that will not be the case.
It'd be the same behaviour as NVCC, which compiles for the lowest architecture it supports. I'm currently implementing Clang CUDA support for CMake and lack of this behaviour compared to other languages and compilers complicates matters. During compiler detection CMake compiles a simple program, which includes preprocessor stuff for embedding compiler info in the output. Then it parses that and determines the compiler vendor, version, etc. The general assumption is that a compiler can compile a simple program for its language without us having to do compiler-specific options, flags, etc. If the compiler fails on this simple program, it's considered broken. A limited list of flags is usually cycled through to support exotic compilers and I could do the same here, but it'd require us invoking the compiler multiple times and increasingly more as old architectures are deprecated. We could detect the CUDA installation ourselves and specify a list of arches for each. This seems quite unnecessary when Clang already knows the version and could select a default that at least compiles. Note that this detection happens before any user CMake files are ran, so we can't pass the user's preferred arch (which could also differ per file). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D75811/new/ https://reviews.llvm.org/D75811 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits