[PATCH] D155850: [Clang][CodeGen][RFC] Add codegen support for C++ Parallel Algorithm Offload

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

> In what regards how to do deferred diagnostics, it think it can be done like this (I crossed streams in my prior reply when discussing this part, so it's actually nonsense): instead of emitting undef here, we can emit a builtin with the same signature, but with the name suffixed with e.g. (`__stdpar_unsupported`) or something similar. Then, when doing the reachability computation later, if we stumble upon a node in the CFG that contains a builtin suffixed with `__stdpar_unsupported` we error out, and can provide nice diagnostics since we'd have the call-chain handy. Thoughts?

Sure, something like that.  If you stick a SourceLocation on it, you can even recover the original clang source location.

> We can definitely go with the __clang_unsupported approach, but I think I'd prefer these to be compile time errors rather than remarks + runtime printf, not in the least because printf adds some overhead.

The overhead should be pretty minimal if the code doesn't actually run.

> So TL;DR, I think it would be more complex to do this on the AST and would end up more brittle / less future proof.



> Since we need to support -O0

The biggest downside of working in the backend is that it becomes very hard for users to predict what will compile, and will not compile.  Particularly if you want to support -O0.  (I was sort of assuming you just wouldn't support -O0.)  If you work on the AST, fewer constructs will be accepted, but you can actually define rules about which constructs will/will not be accepted.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D155850/new/

https://reviews.llvm.org/D155850