Driver only knows how to construct NVPTX compilation pipeline for device side only.
Using NVPTX on the host side violates number of assumptions, trips several assertions and is not expected to produce anything useful in any case. It's better to thow an explicit error instead of letting user figure out what caused compilar to crash.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Driver/ToolChains.cpp | ||
---|---|---|
4834 ↗ | (On Diff #66405) | IRL we talked about putting an assert() here and bailing out earlier. Does that not work? My hope was that we could avoid having to put checks everywhere that the -arch flag is non-empty. Also, if we're going to print an error message saying "you can't use nvptx as the host compiler", it would be nice to do that at some point in the code where we have confidence that someone is actually trying to use nvptx as the host compiler, instead of assuming that, if we get here, that's what happened. |
lib/Driver/ToolChains.cpp | ||
---|---|---|
4834 ↗ | (On Diff #66405) | Haven't found a good place for it yet. |
Abort pipeline constructions early if we detect that NVPTX is used for host compilation.
Restore assertions for presence of -march flag.
Restore assertions for presence of -march flag.
We don't need an explicit assertion in TranslateArgs?
lib/Driver/Driver.cpp | ||
---|---|---|
1412 ↗ | (On Diff #66505) | This is probably worth a comment? |
Nope. The action we create for fatbin uses CudaToolChain, but has nullptr BoundArch and there's no way to tell who's the caller of TranslateArgs().
Added a comment describing why we deliberately error out on use of NVPTX for host compilation.