================
@@ -6440,7 +6440,8 @@ const ToolChain &Driver::getToolChain(const ArgList &Args,
TC = std::make_unique<toolchains::NVPTXToolChain>(*this, Target, Args);
break;
case llvm::Triple::AMDHSA:
- TC = std::make_unique<toolchains::ROCMToolChain>(*this, Target, Args);
+ TC = std::make_unique<toolchains::ROCMToolChain>(*this, Target, Args,
+ Target.isOSWindows());
----------------
david-salinas wrote:
"_I need to wrap my head around this more_"
Yup, the class hierarchy we have created for our tool chains is ...
frustrating, for this case. And I've tried a few different variations just to
be able to tell the Device's ToolChain's RocmInstallationDetector to hold off
on adding these search paths.
"_what's stopping you from just saving that triple inside the class and using
it when we do our detection_"
That was one of my attempts. I first tried just adding it to the
RocmInstallationDetector (RID) class. But because we use the LazyDetector
template, I couldn't change the RID constructor without changing the
LazyDetector template, and I didn't want to mess around with any of the other
Detectors.
So, then I tried just adding a Triple member to the ROCMToolChain class for the
Host Triple, and initializing it in its constructor. Which works. But it is
essentially ends up being the same (or nearly the same) as just passing a flag,
and doing the "work" in the ROCMToolChain constructor. If I use a member
Triple for Host, I would still need to check it in the ROCMToolChain ctor, and
tell its RID that the Host is Windows, before having the RID generate the
search paths.
https://github.com/llvm/llvm-project/pull/113628
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
