hfinkel added a comment. > Still, I think we need to prvide the default implementation of those > non-standard functions (they can be very simple, maybe reporting error is > going to be enough), which can be overriden by user.
I appreciate your motivation, and I agree with you to some extent. I don't object to having generic versions of useful math functions, but I don't think they should be required. It's not reasonable to make someone add generic versions of every function which happens to appear in a system/target-specific math.h header. NVPTX won't be the only target that has target-optimized functions that get pulled in, even from our own headers, but system headers also have differences anyway depending on what preprocessor macros are defined. In the end, people can write portable code if they stick to what's in the standard, and we should make it reasonably easy for them to step outside of the standard to do what they need to do when the standard subset of available functionality doesn't meet their needs for whatever reason. This is what we do for C/C++, where we provide intrinsics and other system functions for those who can't write their code only using the facilities that C/C++ provide. In any case, I think that we can figure out how to add generic versions of non-standard math functions in a separate thread. I think that we should move forward with this and then make progress on generic versions separately. It's also possible that we want to fold this discussion into the discussion on an LLVM math library (we've talked about this for some time in the context of vector math libraries, and I'd not thought about accelerators in this context, but maybe this is all related). Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61399/new/ https://reviews.llvm.org/D61399 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
