https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/84420
>From b0dc390bc52059d7a31b5f0878ffb8024201774d Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 7 Mar 2024 15:48:00 -0600
Subject: [PATCH] [Offload] Move HIP and CUDA to new driver by default
Summary:
jhuber6 wrote:
> > > If `-march` is the wrong option then let's start deprecating it and
> > > remove it altogether in the next llvm release. But, as long as it is
> > > here, it should be equivalent to `--offload-arch`.
> >
> >
> > Honestly not a bad idea. I could make a patch warning users
jhuber6 wrote:
> If `-march` is the wrong option then let's start deprecating it and remove it
> altogether in the next llvm release. But, as long as it is here, it should be
> equivalent to `--offload-arch`.
Honestly not a bad idea. I could make a patch warning users to use
`--offload-arch`
jhuber6 wrote:
> > I don't think we want to support this. `-march` was the wrong option to use
> > in the first place, and upstream LLVM never supported specifying multiple
> > device images with `-march` so there isn't a legacy argument in trunk.
> > However, AOMP did support this and if
jhuber6 wrote:
I don't think we want to support this. `-march` was the wrong option to use in
the first place, and upstream LLVM never supported specifying multiple device
images with `-march` so there isn't a legacy argument in trunk. However, AOMP
did support this and if it's deemed too
Author: Joseph Huber
Date: 2024-05-14T18:43:42-05:00
New Revision: c5cd049566a795ba5de88dfbb2eb563cad4a9d8a
URL:
https://github.com/llvm/llvm-project/commit/c5cd049566a795ba5de88dfbb2eb563cad4a9d8a
DIFF:
https://github.com/llvm/llvm-project/commit/c5cd049566a795ba5de88dfbb2eb563cad4a9d8a.diff
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/91984
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> would it be more useful to allow swapping the output by environment variable
> and MD5 hash, e.g.
>
> CLANG_LINK_WRAPPER_SWAP_OUTPUT=hash1:file1,hash2:file2
>
> it calculates the MD5 hash of the output file, if matching, swap it with the
> specified file. This way, we can
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/91984
>From 4c60b32a4c1916a3ba575d4edc6d79f9b194ab03 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 13 May 2024 10:53:55 -0500
Subject: [PATCH] [LinkerWrapper] Add an overriding option for debugging
Summary:
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/91984
Summary:
One of the downsides of the linker wrapper is that it made debugging
more difficult. It is very powerful in that it can resolve a lot of
input matching and library handling that could not be done before.
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/91264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/91637
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
I hacked around it in the runtime itself. Obviously this is very OpenMP
specific behavior but so was the old method. Passes all tests now.
https://github.com/llvm/llvm-project/pull/91264
___
cfe-commits mailing list
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/91264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 commented:
There's some code in the `clang-linker-wrapper` that creates the offloadbundler
format for HIP offloading. I think it and the tests use `hipv4` which we could
presumably remove now?
https://github.com/llvm/llvm-project/pull/91637
Author: Joseph Huber
Date: 2024-05-09T09:38:22-05:00
New Revision: fa9e90f5d23312587b3a17920941334e0d1a58a1
URL:
https://github.com/llvm/llvm-project/commit/fa9e90f5d23312587b3a17920941334e0d1a58a1
DIFF:
https://github.com/llvm/llvm-project/commit/fa9e90f5d23312587b3a17920941334e0d1a58a1.diff
Author: Joseph Huber
Date: 2024-05-09T07:05:23-05:00
New Revision: e5e66073c3d404f4dedf1b0be160b7815ccf8903
URL:
https://github.com/llvm/llvm-project/commit/e5e66073c3d404f4dedf1b0be160b7815ccf8903
DIFF:
https://github.com/llvm/llvm-project/commit/e5e66073c3d404f4dedf1b0be160b7815ccf8903.diff
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/87009
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/91516
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> Hmm, hard to tell, need to debug it.
Somehow when I print it in the runtime it shows up as garbage, but the actual
region seems to get correct values. There shouldn't be anything in-between the
arguments I'm printing and the kernel launch however so I'm stumped.
jhuber6 wrote:
I'm getting the same kind of output on `main`, but the warning is mysteriously
absent.
https://github.com/llvm/llvm-project/pull/91264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
jhuber6 wrote:
>
> Maybe. The message is emitted on the host, so there is something wrong with
> the host code or runtime library.
This might be some issue with the host codegen actually.
```console
> clang malloc.c -fopenmp -fopenmp-targets=x86_64-pc-linux-gnu
>
https://github.com/jhuber6 approved this pull request.
Hopefully in the future we can handle this in the linker better.
https://github.com/llvm/llvm-project/pull/85672
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
jhuber6 wrote:
> > > > ```llvm
> > > > struct.anon
> > > > ```
> > >
> > >
> > > Can you provide full IR dump here?
> >
> >
> > https://godbolt.org/z/48h5s3W6v
>
> It does not look like the issue of the target code, I don't see any wrong
> access for __context. Мост probably something
jhuber6 wrote:
> > ```llvm
> > struct.anon
> > ```
>
> Can you provide full IR dump here?
https://godbolt.org/z/48h5s3W6v
https://github.com/llvm/llvm-project/pull/91264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/87009
>From 6dfa6dc2956ca714e98bf24b176315da42446553 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 28 Mar 2024 16:18:19 -0500
Subject: [PATCH] [Libomptarget] Statically link all plugin runtimes
Summary:
This
jhuber6 wrote:
> > ```llvm
> > = load i32, ptr %.capture_expr., align 4
> > ```
>
> Why do you think it reads beyond __context? %2 = getelementptr inbounds
> %struct.anon, ptr %1, i32 0, i32 0 points to the first element in the
> __context, if I'm not missing something. If it has the wrong
jhuber6 wrote:
> I did not build upstream but looking at downstream, I think for some reason
> they don't show up as duplicate symbols. But looking at the code, they should
> be removed. There are uses of those variables in the plugin, so there should
> be only 1 definition.
Does this apply
jhuber6 wrote:
> There are duplicate definitions of the following
>
> ```
> bool llvm::omp::target::ompt::Initialized = false;
>
> ompt_get_callback_t llvm::omp::target::ompt::lookupCallbackByCode = nullptr;
> ompt_function_lookup_t llvm::omp::target::ompt::lookupCallbackByName =
> nullptr;
>
jhuber6 wrote:
I'm unsure how to resolve the issue of `CGF.EmitScalarExpr(NumTeams)` not
returning the correct value now. For the following code
```c
#include
#include
int main() {
int Teams = 10;
#pragma omp target teams distribute parallel for num_teams(Teams)
for (int i = 0; i < 1;
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/90994
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/90994
Summary:
Previous patches added support for the LLVM rounding intrinsic
functions. This patch allows them to me emitted using the clang builtins
when targeting AMDGPU.
>From
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/87009
>From 3ea2ae0f5c438b38d0480cfb38a72d2f7a60142c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 28 Mar 2024 16:18:19 -0500
Subject: [PATCH] [Libomptarget] Statically link all plugin runtimes
Summary:
This
jhuber6 wrote:
Going to land this soon.
@jplehr @estewart08 @ronlieb Applied this on the AMD fork, here the diff.
https://gist.github.com/jhuber6/e856fbe9c73acea13b6d30b20605c73e
https://github.com/llvm/llvm-project/pull/87009
___
cfe-commits
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/87009
>From 8c4b7ffb49c8f91768af3bec00669bac5433ec0f Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 28 Mar 2024 16:18:19 -0500
Subject: [PATCH] [Libomptarget] Statically link all plugin runtimes
Summary:
This
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/87009
>From 473a4b9bad09bd9af8186932984be7696711692e Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 28 Mar 2024 16:18:19 -0500
Subject: [PATCH] [Libomptarget] Statically link all plugin runtimes
Summary:
This
jhuber6 wrote:
> > Currently if a user doesn't supply the new "-link-builtin-bitcodes-postopt"
> > option, linking builtin bitcodes happens first, then the optimization
> > pipeline follows. Does that cover the case you're talking about?
>
> I'm thinking of an option that developers can use.
@@ -3476,3 +3472,9 @@ void *AMDGPUDeviceTy::allocate(size_t Size, void *,
TargetAllocTy Kind) {
} // namespace target
} // namespace omp
} // namespace llvm
+
+extern "C" {
+llvm::omp::target::plugin::GenericPluginTy *createPlugin_amdgpu() {
jhuber6 wrote:
I
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/87009
>From 4fd1510c2013fd975ac2ad94b3d201bcd5a9d029 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 28 Mar 2024 16:18:19 -0500
Subject: [PATCH] [Libomptarget] Statically link all plugin runtimes
Summary:
This
https://github.com/jhuber6 approved this pull request.
LG
https://github.com/llvm/llvm-project/pull/89796
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -54,3 +56,76 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions
,
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
DefineStd(Builder, "SPIRV64", Opts);
}
+
+static const AMDGPUTargetInfo AMDGPUTI(llvm::Triple("amdgcn-amd-amdhsa"), {});
+
+ArrayRef
@@ -54,3 +56,76 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions
,
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
DefineStd(Builder, "SPIRV64", Opts);
}
+
+static const AMDGPUTargetInfo AMDGPUTI(llvm::Triple("amdgcn-amd-amdhsa"), {});
+
+ArrayRef
@@ -309,7 +309,45 @@ StringRef AMDGPU::getCanonicalArchName(const Triple ,
StringRef Arch) {
void AMDGPU::fillAMDGPUFeatureMap(StringRef GPU, const Triple ,
StringMap ) {
// XXX - What does the member GPU mean if device name string passed
@@ -309,7 +309,45 @@ StringRef AMDGPU::getCanonicalArchName(const Triple ,
StringRef Arch) {
void AMDGPU::fillAMDGPUFeatureMap(StringRef GPU, const Triple ,
StringMap ) {
// XXX - What does the member GPU mean if device name string passed
@@ -6088,6 +6088,9 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
StringRef Prefix =
llvm::Triple::getArchTypePrefix(getTarget().getTriple().getArch());
if (!Prefix.empty()) {
+if (Prefix == "spv" &&
+
@@ -6088,6 +6088,9 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
StringRef Prefix =
llvm::Triple::getArchTypePrefix(getTarget().getTriple().getArch());
if (!Prefix.empty()) {
+if (Prefix == "spv" &&
+
@@ -54,3 +56,77 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions
,
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
DefineStd(Builder, "SPIRV64", Opts);
}
+
+namespace {
+const AMDGPUTargetInfo AMDGPUTI(llvm::Triple("amdgcn-amd-amdhsa"), {});
+
+} //
@@ -54,3 +56,77 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions
,
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
DefineStd(Builder, "SPIRV64", Opts);
}
+
+namespace {
+const AMDGPUTargetInfo AMDGPUTI(llvm::Triple("amdgcn-amd-amdhsa"), {});
+
+} //
@@ -673,8 +673,12 @@ std::unique_ptr AllocateTarget(const
llvm::Triple ,
}
case llvm::Triple::spirv64: {
if (os != llvm::Triple::UnknownOS ||
-Triple.getEnvironment() != llvm::Triple::UnknownEnvironment)
+Triple.getEnvironment() !=
Author: Joseph Huber
Date: 2024-04-28T06:36:09-05:00
New Revision: bfd269d0d0d6cb58235a838eb659eef97e4f2ebf
URL:
https://github.com/llvm/llvm-project/commit/bfd269d0d0d6cb58235a838eb659eef97e4f2ebf
DIFF:
https://github.com/llvm/llvm-project/commit/bfd269d0d0d6cb58235a838eb659eef97e4f2ebf.diff
jhuber6 wrote:
> I disagree, `--gcc-install-dir` is sure an improvement over
> `--gcc-toolchain`, but they're both weaker than the compile time option
> `GCC_INSTALL_PREFIX` because of runtimes.
>
> You're looking to remove `GCC_INSTALL_PREFIX`, then give a clear alternative
> that's
Author: Joseph Huber
Date: 2024-04-24T07:03:51-05:00
New Revision: eaa2eac8ec73a0473655f2da73f347906d14b00f
URL:
https://github.com/llvm/llvm-project/commit/eaa2eac8ec73a0473655f2da73f347906d14b00f
DIFF:
https://github.com/llvm/llvm-project/commit/eaa2eac8ec73a0473655f2da73f347906d14b00f.diff
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/89803
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> That's not a bad idea but I _suspect_ we'll run into a physical design issue
> since there doesn't seem to be a natural place to put the shared base -
> unless you were thinking about a place in particular? We'd probably have to
> relocate this to the AMDGCN side, and then
jhuber6 wrote:
> > How much of this is actually different from the existing target info for
> > AMDGCN? Seems like we're doing a lot of redundant stuff like defining
> > macros or features.
>
> That's part of the point, it's not actually supposed to differ in those
> particular regards, up
https://github.com/jhuber6 commented:
How much of this is actually different from the existing target info for
AMDGCN? Seems like we're doing a lot of redundant stuff like defining macros or
features.
https://github.com/llvm/llvm-project/pull/89796
jhuber6 wrote:
Note that this doesn't affect OpenMP or HIP. The former uses the
`clang-linker-wrapper` while the latter calls `lld` directly.
https://github.com/llvm/llvm-project/pull/89803
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/89803
Summary:
The AMDGPU toolchain simply took the short name to get the link job
instead of using the common utilities that respect options like
`-fuse-ld`. Any linker that isn't `ld.lld` will fail, however we should
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/87009
>From 50099312ab7c60b8cfce5473a4c154f8d917dc41 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 27 Mar 2024 15:27:16 -0500
Subject: [PATCH 1/3] [Libomptarget] Rename `libomptarget.rtl.x86_64` to
jhuber6 wrote:
It's definitely not ideal that this prints a non-existent path if the
per-target runtime directory configuration is off. Couldn't we just do a
trivial filesystem check to make sure it exists before appending it?
https://github.com/llvm/llvm-project/pull/87866
@@ -0,0 +1,1056 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier:
jhuber6 wrote:
Seems the documentation builder is complaining, maybe something wrong with the
.rst file.
https://github.com/llvm/llvm-project/pull/88827
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
jhuber6 wrote:
> > Isn't this ABI breaking since we're changing the size of the struct?
> > Shouldn't that necessitate a new version?
> > Also unrelated, I wonder if there's a future where we can use the
> > ClangOffloadPackager format in the HIP runtime.
>
> I think you are right. Although
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/88779
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 commented:
Isn't this ABI breaking since we're changing the size of the struct? Shouldn't
that necessitate a new version?
Also unrelated, I wonder if there's a future where we can use the
ClangOffloadPackager format in the HIP runtime.
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/88398
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -86,7 +88,7 @@ static const CudaArchToStringMap arch_names[] = {
// clang-format off
{CudaArch::UNUSED, "", ""},
SM2(20, "compute_20"), SM2(21, "compute_20"), // Fermi
-SM(30), SM(32), SM(35), SM(37), // Kepler
+SM(30), SM3(32, "compute_32"), SM(35),
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/88779
>From dbf6a86930207a4baa787c4387ab83d30524b2aa Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 15 Apr 2024 14:12:15 -0500
Subject: [PATCH] [CUDA] Rename SM_32 to _SM_32 to work around AIX headers
@@ -3466,7 +3466,7 @@ void CGOpenMPRuntimeGPU::processRequiresDirective(
case CudaArch::SM_20:
case CudaArch::SM_21:
case CudaArch::SM_30:
- case CudaArch::SM_32:
+ case CudaArch::_SM_32:
jhuber6 wrote:
Thanks, for some reason my
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/88779
>From 5440db2ad12cc7f47cf7338a1f963c753b0a9f78 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 15 Apr 2024 14:12:15 -0500
Subject: [PATCH] [CUDA] Rename SM_32 to _SM_32 to work around AIX headers
@@ -50,6 +50,10 @@ const char *CudaVersionToString(CudaVersion V);
// Input is "Major.Minor"
CudaVersion CudaStringToVersion(const llvm::Twine );
+// We have a name conflict with sys/mac.h on AIX
+#ifdef SM_32
+#undef SM_32
+#endif
jhuber6 wrote:
Done in
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/88779
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/88779
>From 78662e53fd1309d1e75eb144a2759c580800fd0d Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 15 Apr 2024 14:12:15 -0500
Subject: [PATCH] [CUDA] Rename SM_32 to _SM_32 to work around AIX headers
@@ -50,6 +50,10 @@ const char *CudaVersionToString(CudaVersion V);
// Input is "Major.Minor"
CudaVersion CudaStringToVersion(const llvm::Twine );
+// We have a name conflict with sys/mac.h on AIX
+#ifdef SM_32
+#undef SM_32
+#endif
jhuber6 wrote:
Good point,
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/88779
Summary:
AIX headers define this, so we need to work around it. In the future
this will be removed but for now we should just rename it to avoid these
issues.
>From 0020d59172d819cbe95820f00ffdeb0712f5f2b8 Mon
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/88644
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -50,6 +50,10 @@ const char *CudaVersionToString(CudaVersion V);
// Input is "Major.Minor"
CudaVersion CudaStringToVersion(const llvm::Twine );
+// We have a name conflict with sys/mac.h on AIX
+#ifdef SM_32
+#undef SM_32
+#endif
jhuber6 wrote:
Just naming
@@ -50,6 +50,10 @@ const char *CudaVersionToString(CudaVersion V);
// Input is "Major.Minor"
CudaVersion CudaStringToVersion(const llvm::Twine );
+// We have a name conflict with sys/mac.h on AIX
+#ifdef SM_32
+#undef SM_32
+#endif
jhuber6 wrote:
I mean,
@@ -50,6 +50,10 @@ const char *CudaVersionToString(CudaVersion V);
// Input is "Major.Minor"
CudaVersion CudaStringToVersion(const llvm::Twine );
+// We have a name conflict with sys/mac.h on AIX
+#ifdef SM_32
+#undef SM_32
+#endif
jhuber6 wrote:
We could
@@ -50,6 +50,10 @@ const char *CudaVersionToString(CudaVersion V);
// Input is "Major.Minor"
CudaVersion CudaStringToVersion(const llvm::Twine );
+// We have a name conflict with sys/mac.h on AIX
+#ifdef SM_32
+#undef SM_32
+#endif
jhuber6 wrote:
We already
jhuber6 wrote:
I can't really think of anything more clever here unfortunately and we should
probably unbreak the bot. Maybe someone more familiar with PowerPC knows if
it's possible to simply not include this header somewhere.
https://github.com/llvm/llvm-project/pull/88644
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/88644
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -50,6 +50,11 @@ const char *CudaVersionToString(CudaVersion V);
// Input is "Major.Minor"
CudaVersion CudaStringToVersion(const llvm::Twine );
+// We have a name conflict with sys/mac.h on AIX
+#ifdef _AIX
+#undef SM_32
+#endif
+
jhuber6 wrote:
jhuber6 wrote:
Went ahead and applied this locally. Runs some trivial CUDA / HIP programs so
I'd say it's fine. I'll wait until @Artem-B or @yxsamliu chime in however as
they're the main contributors to this part.
https://github.com/llvm/llvm-project/pull/88559
jhuber6 wrote:
> > Have you run the CUDA / HIP tests in the external test suite or anything?
>
> No, just `check-clang` target. You think it's necessary to run something else
> before merging? If so, you should point me out to what to run, and preferably
> give some instructions, as CUDA
jhuber6 wrote:
I definitely like moving things out of Sema, since it's so big it always brings
my LSP to its knees. Have you run the CUDA / HIP tests in the external test
suite or anything?
https://github.com/llvm/llvm-project/pull/88559
___
jhuber6 wrote:
I'm wondering if it would be better to make this something that the toolchains
handle in `TranslateArgs`. That way we can prevent it from being added at all.
Although I don't know how that would allow us to override stuff. There's not
really a way to "override" flags like this
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/88190
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -201,3 +201,16 @@
! RUN: -nogpulibc %s 2>&1 \
! RUN: | FileCheck --check-prefix=NO-LIBC-GPU-AMDGPU %s
! NO-LIBC-GPU-AMDGPU-NOT: "-lcgpu-amdgpu"
+
+! RUN: rm -rf %t/Inputs
+! RUN: mkdir -p %t/Inputs
+! RUN: cp -r %S/../../../clang/test/Driver/Inputs/rocm
@@ -0,0 +1,39 @@
+// Check that -fcf-protection does not get passed to the device-side
+// compilation.
+
+// RUN: %clang -### -x cuda --target=x86_64-unknown-linux-gnu -nogpulib \
+// RUN: -nogpuinc --offload-arch=sm_52 -fcf-protection=full -c %s 2>&1 \
+// RUN: | FileCheck %s
@@ -6867,8 +6867,14 @@ void Clang::ConstructJob(Compilation , const JobAction
,
CmdArgs.push_back("-nogpulib");
if (Arg *A = Args.getLastArg(options::OPT_fcf_protection_EQ)) {
-CmdArgs.push_back(
-Args.MakeArgString(Twine("-fcf-protection=") +
@@ -345,7 +345,13 @@ void Flang::AddAMDGPUTargetArgs(const ArgList ,
// Check ROCm path if specified
const ToolChain = getToolChain();
- TC.getDeviceLibs(Args);
+ std::string HIPVersion;
+ llvm::raw_string_ostream HIPInfo(HIPVersion);
+ TC.printVerboseInfo(HIPInfo);
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/88402
>From 9b9cbaa09425a706eaf3bb8e85a824ef89b61a9f Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 11 Apr 2024 10:36:15 -0500
Subject: [PATCH] [Offload] Do not pass `-fcf-protection=` for offloading
Summary:
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/88402
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/88402
Summary:
This patch prevents the `-fcf-protection=` flag from being passed to the
device compilation during offloading. This is not supported on CUDA and
AMD devices, but if the user is compiling with fcf
@@ -345,7 +345,13 @@ void Flang::AddAMDGPUTargetArgs(const ArgList ,
// Check ROCm path if specified
const ToolChain = getToolChain();
- TC.getDeviceLibs(Args);
+ std::string HIPVersion;
+ llvm::raw_string_ostream HIPInfo(HIPVersion);
+ TC.printVerboseInfo(HIPInfo);
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/88398
Summary:
Currently we treat this attribute as a minimum number for the amount of
blocks scheduled on the kernel. However, the doucmentation states that
this applies to CTA's mapped onto a *single* SM. Currently
@@ -345,7 +345,13 @@ void Flang::AddAMDGPUTargetArgs(const ArgList ,
// Check ROCm path if specified
const ToolChain = getToolChain();
- TC.getDeviceLibs(Args);
+ std::string HIPVersion;
+ llvm::raw_string_ostream HIPInfo(HIPVersion);
+ TC.printVerboseInfo(HIPInfo);
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/88280
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 commented:
`clang` already tests this pretty well, but I'd still like to have at least one
check to make sure that `flang` is actually putting `-rpath` in the linker.
https://github.com/llvm/llvm-project/pull/88280
___
1 - 100 of 1249 matches
Mail list logo
