-
Notifications
You must be signed in to change notification settings - Fork 15.2k
Remove Linux search paths on Windows #113628
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3060,6 +3060,9 @@ Generic_GCC::Generic_GCC(const Driver &D, const llvm::Triple &Triple, | |
| : ToolChain(D, Triple, Args), GCCInstallation(D), | ||
| CudaInstallation(D, Triple, Args), RocmInstallation(D, Triple, Args) { | ||
| getProgramPaths().push_back(getDriver().Dir); | ||
| llvm::Triple TargetTriple(D.getTargetTriple()); | ||
| if (!TargetTriple.isOSWindows()) | ||
| RocmInstallation->init(); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The RocmInstallation should handle Windows, even if it fails, rather than just masking it here and elsewhere. |
||
| } | ||
|
|
||
| Generic_GCC::~Generic_GCC() {} | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -425,6 +425,12 @@ MSVCToolChain::MSVCToolChain(const Driver &D, const llvm::Triple &Triple, | |
| const ArgList &Args) | ||
| : ToolChain(D, Triple, Args), CudaInstallation(D, Triple, Args), | ||
| RocmInstallation(D, Triple, Args) { | ||
|
|
||
| // Tell the ROCm installation detector that Host is Windows before trying to | ||
| // find HIPRT or Device Libs | ||
| RocmInstallation->setHostWindows(true); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Toolchain constructor should not imply host |
||
| RocmInstallation->init(); | ||
|
|
||
| getProgramPaths().push_back(getDriver().Dir); | ||
|
|
||
| std::optional<llvm::StringRef> VCToolsDir, VCToolsVersion; | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| // REQUIRES: target={{.*-linux.*}} | ||
|
|
||
| // Test to ensure that on Windows, we do not include linux sesrch paths | ||
| // RUN: %clang -### -nogpulib -nogpuinc \ | ||
| // RUN: --print-rocm-search-dirs %s 2>&1 \ | ||
| // RUN: | FileCheck %s | ||
|
|
||
| // CHECK: ROCm installation search path: {{/usr/local}} | ||
| // CHECK: ROCm installation search path: {{/usr}} |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,9 @@ | ||
| // REQUIRES: target={{.*-windows.*}} | ||
|
|
||
| // Test to ensure that on Windows, we do not include linux sesrch paths | ||
| // RUN: %clang -### -nogpulib -nogpuinc \ | ||
| // RUN: --print-rocm-search-dirs %s 2>&1 \ | ||
| // RUN: | FileCheck %s | ||
|
|
||
| // CHECK-NOT: ROCm installation search path: {{/usr/local}} | ||
| // CHECK-NOT: ROCm installation search path: {{/usr}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to pass something implied by the triple when we already have the triple? Also, this is for directly targeting via
--target=amdgcn-amd-amdhsa, which isn't Windows.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason we need to pass this is primarily/solely because when we create the Offloading Device ToolChain (in "Driver::getOffloadingDeviceToolChain()", we pass the Device's triple to the toolchain constructor as the target triple; which as you mentioned will not be Windows. Then the Device side toolchain, has it's own RocmInstallationDetector, which will add the linux paths. And I need a way to tell the RocmInstallationDetector, on the device side ToolChain, that the Host TC is actually Windows.
I tried a couple of different approaches to handle this case, but this is the least intrusive so far. The RocmInstallationDetector sets the search paths in its constructor, and all of the ToolChains that have a Rocm Detector call its constructor in their respective initialize list in their constructors. I need a way to tell that detector instance (for a device side toolchain) that it's Host ToolChain is windows and to not add the linux search paths.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to wrap my head around this more. We create multiple toolchains for offloading, the host toolchain and then the additional ones for offloading. All of those toolchains inherit from
Generic_GCCin this case which initializes the detector. For the host toolchain this will just be the normal host triple, but for the GPU it should be the GPU target. Since we have the triple in the installation detector, we should just be able to change behavior if the OS is windows? We have the triple argument for ROCm we just don't use it, what's stopping you from just saving that triple inside the class and using it when we do our detection?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
RIDalready has the host triple available I thoughtllvm-project/clang/lib/Driver/ToolChains/ROCm.h
Line 169 in 3734e4c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, we call it "HostTriple", but in the case for a Device side ToolChain, the triple passed to the TC's ctor (which is the same triple passed to the RID ctor) is going to be the device triple, which is always (I think) amdgcn-amd-amdhsa, or at least definitely not Windows. We can use the TC's triple for removing the linux search paths for Host side. But the problem is that this doesn't work when we create the Device TC, and it's RID.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we actually require the ROCm installation from the device's TC? I guess it'd be used when making the device interface? The
HIPAMDToolChainhas a reference to the host toolchain, so I'd argue that we should use that one's ROCm installation and never use the device one.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jhuber6 So I spent some time trying to rework this to do just what you suggested (have the HIPAMDToolChain, just use the HostTC's RocmInstallation), because it is a good idea :-) But ... I ran into design issues. The member "HostTC" of HIPAMDToolChain, is a "const ToolChain &". And the "ToolChain" class does not have a "RocmInstallation" member, it is a member of the child class "Generic_GCC". We could cast "HostTC" reference to a Generic_GCC object reference (just in the HIPAMDToolClass), but that solution doesn't feel very pretty either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do stuff like this in a ton of places,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah ... ok. :-)