jhuber6 wrote:
> IIRC there is a case where `omp.h` as well as other headers are installed
> into clang's directory.
These are currently installed into clang's directory, this patch just puts it
in the resource directory for the build.
https://github.com/llvm/llvm-project/pull/88007
_
@@ -16,4 +16,12 @@ typedef unsigned __INTPTR_TYPE__ uintptr_t;
#error Every target should have __INTPTR_TYPE__
#endif
+#ifdef __INTPTR_MAX__
+#define INTPTR_MAX__INTPTR_MAX__
+#endif
+
+#ifdef __UINTPTR_MAX__
+#define UINTPTR_MAX __UINTPTR_MAX__
+#endif
+
--
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/88007
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -16,4 +16,12 @@ typedef unsigned __INTPTR_TYPE__ uintptr_t;
#error Every target should have __INTPTR_TYPE__
#endif
+#ifdef __INTPTR_MAX__
+#define INTPTR_MAX__INTPTR_MAX__
+#endif
+
+#ifdef __UINTPTR_MAX__
+#define UINTPTR_MAX __UINTPTR_MAX__
+#endif
+
--
@@ -10,12 +10,19 @@
include(ExtendPath)
+# The generated headers will be placed in clang's resource directory if
present.
+if(${OPENMP_STANDALONE_BUILD})
+ set(LIBOMP_HEADERS_INTDIR ${CMAKE_CURRENT_BINARY_DIR})
+else()
+ set(LIBOMP_HEADERS_INTDIR ${LLVM_BINARY_DIR}/${LIBOM
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/88007
___
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/88071
Summary:
These entires are generic for offloading with the new driver now. Having
the `omp` prefix was a historical artifact and is confusing when used
for CUDA. This patch just renames them for now, future patche
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/88071
>From e236a4351c198f261e544970d4355f749db11fd7 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 8 Apr 2024 19:10:37 -0500
Subject: [PATCH] [Offload][NFC] Remove `omp_` prefix from offloading entries
Summar
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/88071
>From 24c3253093491d0fbe297bc10cba8552b7bef665 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 8 Apr 2024 19:10:37 -0500
Subject: [PATCH] [Offload][NFC] Remove `omp_` prefix from offloading entries
Summar
jhuber6 wrote:
> How about `llvm.offload`? This might need broader discussion but I'm fine
> either way.
I don't think it's too important here since these are effectively internal
variables. However in the future I want to combine `cuda_offload_entires` and
friends into just `llvm_offload_ent
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/88071
>From 198e77ad14ff83d2ed9ea80a1dcecafa1b1336a0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 8 Apr 2024 19:10:37 -0500
Subject: [PATCH] [Offload][NFC] Remove `omp_` prefix from offloading entries
Summar
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/88071
>From c94d444b4317706c7434853c0c3490826bdbc110 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 8 Apr 2024 19:10:37 -0500
Subject: [PATCH] [Offload][NFC] Remove `omp_` prefix from offloading entries
Summar
jhuber6 wrote:
> Hey, @jhuber. This change broke the flang build.
>
> When I revert the change, everything builds cleanly. So I reverted it in
> merge request #88083.
>
> After this change was added, I started getting messages like:
>
> ```
> [4/205] Building CXX object
> projects/openmp/lib
jhuber6 wrote:
> Hey, @jhuber. This change broke the flang build.
>
> When I revert the change, everything builds cleanly. So I reverted it in
> merge request #88083.
>
> After this change was added, I started getting messages like:
>
> ```
> [4/205] Building CXX object
> projects/openmp/lib
jhuber6 wrote:
> So the error is caused by your `c++` not supporting `__has_feature`
> presumably. However I have no clue why that would happen due to this patch. I
> believe in a few days @jdoerfert will flip the switch and we won't even allow
> `libomptarget` to be built without using the ru
jhuber6 wrote:
> I should have mentioned, I'm building with GCC 9.3.0. Most of my team uses
> this compiler.
Yeah, that's fine for building LLVM but in the future we'll probably require
building the offloading runtime with an up-to-date clang. I think for now I can
just restrict this patch to
Author: Joseph Huber
Date: 2024-04-09T08:47:51-05:00
New Revision: d022f6b8ff94bb13d12d39f23a3c3e7836e90756
URL:
https://github.com/llvm/llvm-project/commit/d022f6b8ff94bb13d12d39f23a3c3e7836e90756
DIFF:
https://github.com/llvm/llvm-project/commit/d022f6b8ff94bb13d12d39f23a3c3e7836e90756.diff
jhuber6 wrote:
ping
https://github.com/llvm/llvm-project/pull/87532
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> if a.o depends on b.o in libb.a, and b.o depends on c.o in libb.a, will the
> linker wrapper be able to link all the dependencies?
Given an invocation like this with those dependencies
```console
$ clang main.o libb.a liba.a
```
main.o will extract `a.o` from `liba.a`. We will
@@ -201,3 +201,24 @@
! 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: not %flang -### -v --target=x86_64-unknown-linux-gnu -fopenmp \
+! RUN: --off
@@ -1340,7 +1340,8 @@ def hip_link : Flag<["--"], "hip-link">,
Group,
HelpText<"Link clang-offload-bundler bundles for HIP">;
def no_hip_rt: Flag<["-"], "no-hip-rt">, Group,
HelpText<"Do not link against HIP runtime libraries">;
-def rocm_path_EQ : Joined<["--"], "rocm-pat
@@ -342,6 +342,10 @@ void Flang::AddAMDGPUTargetArgs(const ArgList &Args,
StringRef Val = A->getValue();
CmdArgs.push_back(Args.MakeArgString("-mcode-object-version=" + Val));
}
+
+ // Check ROCm path if specified
+ const ToolChain &TC = getToolChain();
+ TC.getDev
@@ -201,3 +201,24 @@
! 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: not %flang -### -v --target=x86_64-unknown-linux-gnu -fopenmp \
+! RUN: --off
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/88071
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1340,7 +1340,8 @@ def hip_link : Flag<["--"], "hip-link">,
Group,
HelpText<"Link clang-offload-bundler bundles for HIP">;
def no_hip_rt: Flag<["-"], "no-hip-rt">, Group,
HelpText<"Do not link against HIP runtime libraries">;
-def rocm_path_EQ : Joined<["--"], "rocm-pat
@@ -342,6 +342,10 @@ void Flang::AddAMDGPUTargetArgs(const ArgList &Args,
StringRef Val = A->getValue();
CmdArgs.push_back(Args.MakeArgString("-mcode-object-version=" + Val));
}
+
+ // Check ROCm path if specified
+ const ToolChain &TC = getToolChain();
+ TC.getDev
@@ -201,3 +201,24 @@
! 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: not %flang -### -v --target=x86_64-unknown-linux-gnu -fopenmp \
+! RUN: --off
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/87532
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 commented:
Seems somewhat superfluous to me. I'm wondering if what this customer wants to
do is more easily serviced by `#if __has_builtin(...)` or `#if
__has_feature(...)`. However I definitely agree that our feature detection
macros are a bit of a mess. I'm not pri
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
___
cfe-c
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
@@ -345,7 +345,13 @@ void Flang::AddAMDGPUTargetArgs(const ArgList &Args,
// Check ROCm path if specified
const ToolChain &TC = getToolChain();
- TC.getDeviceLibs(Args);
+ std::string HIPVersion;
+ llvm::raw_string_ostream HIPInfo(HIPVersion);
+ TC.printVerboseInfo(HIP
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 we
@@ -345,7 +345,13 @@ void Flang::AddAMDGPUTargetArgs(const ArgList &Args,
// Check ROCm path if specified
const ToolChain &TC = getToolChain();
- TC.getDeviceLibs(Args);
+ std::string HIPVersion;
+ llvm::raw_string_ostream HIPInfo(HIPVersion);
+ TC.printVerboseInfo(HIP
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 protecti
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 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:
@@ -345,7 +345,13 @@ void Flang::AddAMDGPUTargetArgs(const ArgList &Args,
// Check ROCm path if specified
const ToolChain &TC = getToolChain();
- TC.getDeviceLibs(Args);
+ std::string HIPVersion;
+ llvm::raw_string_ostream HIPInfo(HIPVersion);
+ TC.printVerboseInfo(HIP
@@ -6867,8 +6867,14 @@ void Clang::ConstructJob(Compilation &C, const JobAction
&JA,
CmdArgs.push_back("-nogpulib");
if (Arg *A = Args.getLastArg(options::OPT_fcf_protection_EQ)) {
-CmdArgs.push_back(
-Args.MakeArgString(Twine("-fcf-protection=") + A->getVal
@@ -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
@@ -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 %t/Input
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
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 i
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
___
cfe-comm
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 devel
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
@@ -50,6 +50,11 @@ const char *CudaVersionToString(CudaVersion V);
// Input is "Major.Minor"
CudaVersion CudaStringToVersion(const llvm::Twine &S);
+// We have a name conflict with sys/mac.h on AIX
+#ifdef _AIX
+#undef SM_32
+#endif
+
jhuber6 wrote:
```sugges
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
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 created
https://github.com/llvm/llvm-project/pull/83906
Summary:
This patch implements the LLVM floating point environment control
intrinsics and also exposes it through clang. We encode the floating
point environment as a 64-bit value that simply concatenates the valu
jhuber6 wrote:
Note that this patch is not quite ready to land. I encountered issues when
working with `s_setreg`. The listing of `SOPK` instructions should have this as
an instruction that takes a 16-bit zero extended immediate value. However, this
was apparently not the case for the `s_setre
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/83906
>From d7e20596434636753610ceb4326ddc1116f0bdce Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 1 Mar 2024 15:28:32 -0600
Subject: [PATCH] [AMDGPU] Implement 'llvm.get.fpenv' and 'llvm.set.fpenv'
Summary:
@@ -1122,7 +1122,7 @@ class S_SETREG_B32_Pseudo pattern=[]> :
SOPK_Pseudo <
pattern>;
def S_SETREG_B32 : S_SETREG_B32_Pseudo <
- [(int_amdgcn_s_setreg (i32 SIMM16bit:$simm16), i32:$sdst)]> {
+ [(int_amdgcn_s_setreg (i32 timm:$simm16), i32:$sdst)]> {
jhub
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/83906
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1122,7 +1122,7 @@ class S_SETREG_B32_Pseudo pattern=[]> :
SOPK_Pseudo <
pattern>;
def S_SETREG_B32 : S_SETREG_B32_Pseudo <
- [(int_amdgcn_s_setreg (i32 SIMM16bit:$simm16), i32:$sdst)]> {
+ [(int_amdgcn_s_setreg (i32 timm:$simm16), i32:$sdst)]> {
jhub
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/83906
>From e349a9d436cdb99f0d9fb8d6df772a600ca0ea94 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 1 Mar 2024 15:28:32 -0600
Subject: [PATCH] [AMDGPU] Implement 'llvm.get.fpenv' and 'llvm.set.fpenv'
Summary:
@@ -1122,7 +1122,7 @@ class S_SETREG_B32_Pseudo pattern=[]> :
SOPK_Pseudo <
pattern>;
def S_SETREG_B32 : S_SETREG_B32_Pseudo <
- [(int_amdgcn_s_setreg (i32 SIMM16bit:$simm16), i32:$sdst)]> {
+ [(int_amdgcn_s_setreg (i32 timm:$simm16), i32:$sdst)]> {
jhub
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/83927
Summary:
The AMDGPU traget was originally designed with OpenCL in mind. The first
verisions only provided the grid size, which is the total numver of
threads in the execution context. In order to get the number of
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/83927
>From 56059fdb5a0e22f8c7dcce6642899fdccf77a55b Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 4 Mar 2024 17:27:28 -0600
Subject: [PATCH] [AMDGPU] Introduce 'amdgpu_num_workgroups_{xyz}' builtin
Summary:
https://github.com/jhuber6 commented:
We had a lot that were like this previously. Guessing this one slipped through
because of the `zlib` requirement. Does this work with `-nogpulib` instead?
Usually easier than passing the dummy CUDA path.
https://github.com/llvm/llvm-project/pull/84008
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/83906
>From 7808b8a0f4ab70733ebff4a6b8793f4918d0107b Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 1 Mar 2024 15:28:32 -0600
Subject: [PATCH] [AMDGPU] Implement 'llvm.get.fpenv' and 'llvm.set.fpenv'
Summary:
jhuber6 wrote:
> It definitely doesn't work for the "pure" CUDA invocations, it still finds my
> local installation and complains. It might work for the OpenMP invocations,
> but hard to tell for me on a system with CUDA installed. As it's a `.cu` test
> after all, I think I would prefer the u
jhuber6 wrote:
> > Might need `-nogpulib -nogpuinc` in those cases, we do that in other `.cu`
> > files in the test suite.
>
> No, I already tried that, it doesn't work for me. All
> `clang/test/Driver/*.cu` that supply `-nocudainc` also pass `--cuda-path`...
The only reason it will fail with
@@ -325,6 +325,9 @@ BUILTIN(__builtin_amdgcn_read_exec_hi, "Ui", "nc")
BUILTIN(__builtin_amdgcn_endpgm, "v", "nr")
+BUILTIN(__builtin_amdgcn_get_fpenv, "WUi", "n")
jhuber6 wrote:
There's no builtin as far as I'm aware. I think there might be some pragmas
ho
jhuber6 wrote:
In any case, it's not really important and this works. I'm mostly just curious
why it doesn't seem to work as I would expect since there might be something to
fix.
https://github.com/llvm/llvm-project/pull/84008
___
cfe-commits mailing
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/83906
>From 169f8914270725bd94b14a20f5f91005ce59f494 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 1 Mar 2024 15:28:32 -0600
Subject: [PATCH] [AMDGPU] Implement 'llvm.get.fpenv' and 'llvm.set.fpenv'
Summary:
jhuber6 wrote:
> The invocations in `clang/test/Driver/cuda-omp-unsupported-debug-options.cu`
> don't pass `-emit-llvm` but `-###`.
>
> ```
> > cat /dev/null | ./bin/clang -### -x cuda - -nogpulib -nogpuinc -c && echo
> $?
> ```
>
> should error with recent CUDA installations because of `sm_
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/84017
Summary:
We already had a special CUDA default that better tracked the state as
of modern CUDA installations. Recently this was bumped up to `sm_52`,
but there was a location that wasn't respecting this. Fix that.
jhuber6 wrote:
Found it https://github.com/llvm/llvm-project/pull/84017.
https://github.com/llvm/llvm-project/pull/84008
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> Ok, but that still doesn't change the fact that the Clang driver will search
> for a system-wide CUDA installation unless passed `--cuda-path`...
We also do this with the GCC toolchain, the issue is whether or not there's an
error if it didn't find it. Doing `clang -v` will al
@@ -839,6 +839,18 @@ unsigned test_wavefrontsize() {
return __builtin_amdgcn_wavefrontsize();
}
+// CHECK-LABEL test_get_fpenv(
jhuber6 wrote:
Is this related to the DX10 clamp / traps potentially being disabled? Or is
this an LLVM concept.
https://github
@@ -839,6 +839,18 @@ unsigned test_wavefrontsize() {
return __builtin_amdgcn_wavefrontsize();
}
+// CHECK-LABEL test_get_fpenv(
jhuber6 wrote:
Hm, I'm not sure. I feel like this is just letting the user access the hardware
directly which has a different us
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/83906
>From 1cb734f3df298a34d76f7c9ee059dff84ba50c10 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 1 Mar 2024 15:28:32 -0600
Subject: [PATCH] [AMDGPU] Implement 'llvm.get.fpenv' and 'llvm.set.fpenv'
Summary:
@@ -839,6 +839,18 @@ unsigned test_wavefrontsize() {
return __builtin_amdgcn_wavefrontsize();
}
+// CHECK-LABEL test_get_fpenv(
jhuber6 wrote:
Added a sema check.
https://github.com/llvm/llvm-project/pull/83906
_
jhuber6 wrote:
> @jhuber6 unfortunately after
> [2fb764d](https://github.com/llvm/llvm-project/commit/2fb764d2dae288f24335dfc168b5491a1017fc83)
>
> ```
> ls
> /soft/compilers/llvm/master-nightly/lib/x86_64-unknown-linux-gnu/libomptarget.rtl*
> /soft/compilers/llvm/master-nightly/lib/x86_64-unk
jhuber6 wrote:
> @jhuber6 could you build openmp as a project instead of runtime?
Ah, I could try that. Though I believe that Johannes is going to completely
deprecate the projects build once moving to llvm/offload.
https://github.com/llvm/llvm-project/pull/83282
__
jhuber6 wrote:
> @jdoerfert I would like to see the device code compilation (on device
> runtime) and host runtime compilation fully separate. Then I can build the
> runtime with gcc or sanitizer without disturbing device code compilation.
Could you elaborate on this? One of my long-term goals
jhuber6 wrote:
> > > @jdoerfert I would like to see the device code compilation (on device
> > > runtime) and host runtime compilation fully separate. Then I can build
> > > the runtime with gcc or sanitizer without disturbing device code
> > > compilation.
> >
> >
> > Could you elaborate on
jhuber6 wrote:
> Could you explain what each line does exactly?
This is hypothetical, but it's a potential way to keep it from having a
separate project
`-DLLVM_RUNTIME_TARGETS=default;amdgcn-amd-amdhsa;nvptx64-nvidia-cuda`
Enables the runtimes for the target triples, default is what you get wi
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/84017
>From e4c58b869c2534f58e0b433a73b42a507477c694 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 5 Mar 2024 07:44:48 -0600
Subject: [PATCH 1/2] [CUDA] Correctly set CUDA default architecture
Summary:
We alr
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/84017
>From d1bdd2af7e0c29f69315d8f7f87439538f10f5ca Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 5 Mar 2024 07:44:48 -0600
Subject: [PATCH] [CUDA] Correctly set CUDA default architecture
Summary:
We already
jhuber6 wrote:
> Fixed the issue
> [0fa04b6](https://github.com/llvm/llvm-project/commit/0fa04b6e2cd2169a8e3d22ae879394dbf07c0466)
> Unrelated to building as projects.
Hah, I probably should've noticed that. Explains why I didn't notice because I
always have tests enabled.
https://github.com
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/83906
>From 1ff47a0c18e5f163bad9c0bd45c987ff7a33ab83 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 1 Mar 2024 15:28:32 -0600
Subject: [PATCH] [AMDGPU] Implement 'llvm.get.fpenv' and 'llvm.set.fpenv'
Summary:
@@ -6826,6 +6826,10 @@ def warn_floatingpoint_eq : Warning<
"comparing floating point with == or != is unsafe">,
InGroup>, DefaultIgnore;
+def warn_fenv_access : Warning<
+ "floating point environment access without #pragma STDC FENV_ACCESS set ON">,
+ InGroup>;
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/83906
>From 1ff47a0c18e5f163bad9c0bd45c987ff7a33ab83 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 1 Mar 2024 15:28:32 -0600
Subject: [PATCH 1/2] [AMDGPU] Implement 'llvm.get.fpenv' and 'llvm.set.fpenv'
Summa
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/84017
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> I think we would be better off teaching an IR optimizer pass to recognize the
> divide pattern and remap it to the load from the new location, rather than
> forcing the complexity into every frontend
That's fair. I would've argued that this version should've been the builtin a
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/83978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
Please format before landing
https://github.com/llvm/llvm-project/pull/83978
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2,56 +2,56 @@
// REQUIRES: nvptx-registered-target
// REQUIRES: zlib
-// RUN: not %clang -### --target=x86_64-linux-gnu -c %s -g -gz 2>&1 \
+// RUN: %clang -### --target=x86_64-linux-gnu --offload-arch=sm_52 -nogpulib
-nogpuinc -c %s -g -gz 2>&1 \
// RUN: | FileCheck %s
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/83906
___
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/84195
___
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/84253
Summary:
The very first version of the `clang-linker-wrapper` used `--` as a
separator for the host and device arguments. I moved away from this
towards a commandline parsing implementation years ago but never got
jhuber6 wrote:
> > [NFC]
>
> From a strict interpretation, this is not NFC as this changes clang driver
> behavior. The overall behavior combining clang + clang-linker-wrapper may not
> change, though...
I suppose I just wanted to make it clear that this option didn't do anything,
but it doe
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/84253
___
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/84322
Summary:
The clang-offload-bundler uses an empty file to control the bundles made
for embedding. Previously this still used `/dev/null` by mistake even on
Windows.
>From eb6dd7ac6cfd52ce18b17a683e55835a261f7138
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/84322
>From 4a1e095d962e5b76d529fe579f2b449a36117c65 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 7 Mar 2024 07:48:38 -0600
Subject: [PATCH] [LinkerWrapper] Use the correct empty file on Windows
Summary:
The
@@ -410,7 +410,10 @@ fatbinary(ArrayRef>
InputFiles,
Targets.push_back(Saver.save("hipv4-amdgcn-amd-amdhsa--" + Arch));
CmdArgs.push_back(Saver.save(llvm::join(Targets, ",")));
- CmdArgs.push_back("-input=/dev/null");
+ if (Triple.isOSWindows())
jhube
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/84322
>From 8ffd2e22efc5ae6cc939802f6a2913f334dfcc54 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 7 Mar 2024 07:48:38 -0600
Subject: [PATCH] [LinkerWrapper] Use the correct empty file on Windows
Summary:
The
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/84332
Summary:
The new driver does not need this hash and it can lead to redefined
symbol errors when the CUID hash isn't set.
>From 012ead550448376f4fefd9fb70418e32f02dba6b Mon Sep 17 00:00:00 2001
From: Joseph Huber
501 - 600 of 1001 matches
Mail list logo
