rnk added a comment. In https://reviews.llvm.org/D25166#559168, @jlebar wrote:
> > Also, take a look at CodeGenFunction::getInvokeDestImpl(). I think you > > should add some checks in there to return nullptr if we're doing a > > device-side CUDA compilation. That's a much more direct way to ensure we > > never generate invokes on the device side. > > Hm...if we did this but didn't mark functions as "this never throws", would > that really take care of everything? For example, if we were to call an > external function which is itself not marked as noexcept, llvm wouldn't be > able to infer that we don't throw. > > Are you saying we should do both? I'm happy to do that, but I am not sure, > if we keep the nounwind attribute in, whether it's possible to write a > testcase. I think you want both: you want all device CUDA function definitions (and declarations!) to be marked nounwind to help the optimizer, but you also want to directly make sure clang codegen knows that exceptions are turned off on the device side by changing getInvokeDestImpl. It's essentially the key place we check LangOpts.Exceptions, so if we can't turn that off, then we probably want to inject our CUDA device checks there. >> Can we use a noexcept exception specification instead of this GCC attribute? > > I have no attachment to this specific attribute, but wouldn't adding noexcept > change the semantics of the program (because traits can detect whether or not > noexcept is present)? Hm, yeah, that's no good because then you'll have host vs. device conflicts in those traits. This should probably be a CodeGen-only change anyway, so you might as well add nounwind to function declarations in CGCall.cpp. https://reviews.llvm.org/D25166 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
