Propagates AuxTriple throughout job pipeline construction in driver and on to Tool::ConstructJob().
It in turn passes target triple of opposite side of CUDA compilation as -aux-triple option to sub-compilations.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Would this make more sense to put in the Compilation class rather than on the Action? It seems like it could go next to DefaultToolchain or could even be a separate toolchain itself so that all of the bits could be looked up?
Thanks!
-eric
Instead of passing AuxTriple around as an argument, store ToolChain info in Compilation and retrieve it from there.
Some inline comments for discussion.
Thanks!
-eric
lib/Driver/Driver.cpp | ||
---|---|---|
503 ↗ | (On Diff #38269) | Can pass one or the other here? I don't think you need both a reference to C and one of its members? |
1285–1291 ↗ | (On Diff #38269) | Can't you now do all of this in BuildCompilation? |
lib/Driver/Driver.cpp | ||
---|---|---|
503 ↗ | (On Diff #38269) | I can fold getArgs and getActions for BuildUniversalActions(), but not toolchain as it's called with different ones. |
1285–1291 ↗ | (On Diff #38269) | I could, but i'd prefer to avoid putting hardcoded cuda logic into otherwise generic BuildCompilation for no good reason. Here is where we start creating device-side actions and have all relevant info for that so it appears to be a sensible place to pick an appropriate toolchain for that as well. When we have better support for multiple compilation targets toolchain selection would probably be more generic and would migrate towards BuildCompilation, but we're not there yet. :-) |
Moved CUDA toolchain selection to Compilation.
Removed DeviceTriple info from CudaHostActions and CudaDeviceActions.
Removed few now-unnecessary parameters and code that used them.
Moved CUDA toolchain selection to Driver::BuildCompilation() where Compilation is set up.
One inline comment then OK for now.
-eric
lib/Driver/Tools.cpp | ||
---|---|---|
3227–3240 ↗ | (On Diff #39019) | This is pretty heinous. I don't have a better way of doing it offhand, but please document this with a rather large FIXME and continue on the path to generic compilation support we've been talking about. |
Added a FIXME note regarding figuring out which compilation pass we're constructing.
Undone the change to make getToolchain public as it's no longer accessed from outside of Driver.
Converted the if(AuxToolchain) into assert.