[PATCH] D40250: [OpenMP] Consistently use cubin extension for nvlink

Artem Belevich via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Nov 20 10:39:53 PST 2017


tra added inline comments.


================
Comment at: lib/Driver/ToolChains/Clang.cpp:5341-5344
+    if (const auto *OA = dyn_cast<OffloadAction>(JA.getInputs()[I])) {
+      OA->doOnEachDependence(
+          [&](Action *, const ToolChain *TC, const char *) { CurTC = TC; });
+    }
----------------
Can we ever have more than one dependence? If not, perhaps add an assert.
Otherwise, can dependencies have different toolchains? 
If so, which one do we really want?





================
Comment at: lib/Driver/ToolChains/Cuda.cpp:461
+std::string CudaToolChain::getInputFilename(const InputInfo &Input) const {
+  if (OK != Action::OFK_OpenMP || Input.getType() != types::TY_Object)
+    return ToolChain::getInputFilename(Input);
----------------
Hahnfeld wrote:
> gtbercea wrote:
> > Hahnfeld wrote:
> > > gtbercea wrote:
> > > > When does this situation occur?
> > > Well, if that condition fires:
> > > 1. For CUDA
> > > 2. For other types. For example, the bundler might need to bundle / unbundle assembly files.
> > Can you put this info in a comment just before the if statement?
> I'd say this condition is not the most difficult that I've ever seen, but can do
I usually find conditions expressed in positive terms are much easier to understand at a glance.
I.e. `if (!(OK == Action::OFK_OpenMP && Input.getType() == types::TY_Object))` is, IMO, almost obvious in its meaning, while the condition above required conscious effort to understand its purpose.


================
Comment at: lib/Driver/ToolChains/Cuda.h:144
 
+  virtual std::string getInputFilename(const InputInfo &Input) const override;
+
----------------
`virtual` is redundant here.


https://reviews.llvm.org/D40250





More information about the cfe-commits mailing list