This is an archive of the discontinued LLVM Phabricator instance.

[CUDA] Add Sema::CUDADiagBuilder and Sema::CUDADiagIfDeviceCode().
ClosedPublic

Authored by jlebar on Sep 30 2016, 4:33 PM.

Details

Summary

Together these let you easily create diagnostics that

  • are never emitted for host code
  • are always emitted for device and global functions, and
  • are emitted for host device functions iff these functions are codegen'ed.

At the moment there are only three diagnostics that need this treatment,
but I have more to add, and it's not sustainable to write code for emitting
every such diagnostic twice, and from a special wrapper in SemaCUDA.cpp.

While we're at it, don't emit the function name in
err_cuda_device_exceptions: It's not necessary to print it, and making
this work in the new framework in the face of a null value for
dyn_cast<FunctionDecl>(CurContext) isn't worth the effort.

Diff Detail

Repository
rL LLVM

Event Timeline

jlebar updated this revision to Diff 73161.Sep 30 2016, 4:33 PM
jlebar retitled this revision from to [CUDA] Add Sema::CUDADiagBuilder and Sema::CUDADiagIfDeviceCode()..
jlebar updated this object.
jlebar added a reviewer: rnk.
jlebar added subscribers: tra, cfe-commits.
jlebar updated this revision to Diff 73165.Sep 30 2016, 4:46 PM

Add CUDADiagIfHostCode().

jlebar updated this revision to Diff 73171.Sep 30 2016, 5:31 PM

Tweak API a bit.

Now we rely on an implicit conversion to bool. Which is not great, I know, but
in practice I think works better than an explicit named function.

rnk added inline comments.Oct 3 2016, 11:11 AM
clang/include/clang/Sema/Sema.h
9210 ↗(On Diff #73171)
9238 ↗(On Diff #73171)

I'm concerned that this usage pattern isn't going to be efficient because you build the complete diagnostic before calling the bool conversion operator to determine that it doesn't need to be emitted. I think you want to construct something more like:

if (isCUDADeviceCode())
  CUDADiag(...) << ...;

Otherwise you are going to construct and destruct a large number of diagnostics about language features that are forbidden in device code, but are legal in host code, and 99% of the TU is going to be host code that uses these illegal features.

9258 ↗(On Diff #73171)

Remind me why we need to do this? Which arena is this stuff allocated in and where would I go to read more about it? My thought is that, if we don't construct very many of these, we should just allocate them in the usual ASTContext arena and let them live forever. It would be more consistent with our usual way of doing things.

jlebar updated this revision to Diff 73315.Oct 3 2016, 11:46 AM
jlebar marked an inline comment as done.

Address review comments, and rebase atop https://reviews.llvm.org/D24573.

jlebar added inline comments.Oct 3 2016, 11:48 AM
clang/include/clang/Sema/Sema.h
9238 ↗(On Diff #73171)

I think the comment is misleading -- I tried to update it to resolve this misunderstanding. Does it make more sense now?

9258 ↗(On Diff #73171)

These diagnostics live until the end of codegen, and so are destroyed after the ASTContext.

I am becoming increasingly displeased with emitting these errors during codegen. In particular, it makes it annoying to write tests. You cannot test deferred and immediate errors in the same test, because if you have any immediate errors, we never codegen, so we never emit the deferred ones. This will also be a suboptimal user experience.

The only serious alternative mooted thus far is emitting the deferred errors when a function is marked used. But this is going to emit deferred errors if e.g. two inline host+device functions have mutual recursion but are otherwise never touched (so don't need to be codegen'ed). I am not sure if this will be OK or not, but I need to look at it.

If we move the errors to being emitted earlier, we won't need to do this dance.

rnk added inline comments.Oct 3 2016, 12:51 PM
clang/include/clang/Sema/Sema.h
9258 ↗(On Diff #73171)

The ASTContext should outlive IRgen, since the AST is allocated in its arena. Is there a separate diagnostic memory pool that I don't know about?

jlebar updated this revision to Diff 73576.Oct 4 2016, 4:17 PM
jlebar marked an inline comment as done.

Rebase atop https://reviews.llvm.org/D25260, which obviates the need for this
ugly PD allocation dance.

clang/include/clang/Sema/Sema.h
9258 ↗(On Diff #73171)

You're right, this is a silly bug. Fixed in a separate patch, https://reviews.llvm.org/D25260 -- with that change we can do the natural thing here.

If you're busy with other stuff, that's cool, this is not urgent, but pinging in case this got lost.

rnk accepted this revision.Oct 12 2016, 6:03 PM
rnk edited edge metadata.

lgtm

clang/include/clang/Sema/Sema.h
9238 ↗(On Diff #73171)

Actually, I just had to think about the problem more to realize why it has to be this way. This is for deferred diagnostics where you don't know if the code is device code yet. :)

This revision is now accepted and ready to land.Oct 12 2016, 6:03 PM
This revision was automatically updated to reflect the committed changes.