jhuber6 wrote:
> > It should only be invoking `nvptx-arch` if the user passed `-march=native`.
>
> Sorry, didn't notice this sentence. Well, _I am_ building with
> `-march=native` here — after all, other files are built for a CPU. If I
> change it to, say, `-march=zen2`, then it indeed compile
jhuber6 wrote:
> Nah, building standalone directly. And separately from OpenMP.
I see, it previously worked because when you built with `gcc` it was still
finding `clang` in your environment and using that. I'm going to move this code
so that it's more explicit that we only support a just-buil
jhuber6 wrote:
I disabled my NVIDIA GPU discovery and I could build it successfully. What's
your `clang` version? I'm wondering what could be different here.
https://github.com/llvm/llvm-project/pull/126143
___
cfe-commits mailing list
cfe-commits@lis
jhuber6 wrote:
> How did you disable it? Perhaps it's failing because of the specific error:
>
> ```
> $ nvptx-arch
>
> Failed to 'dlopen' libcuda.so.1
> ```
>
> For comparison, `amdgpu-
jhuber6 wrote:
> No, I'm afraid that didn't change anything. However, it did if I added it to
> `target_link_options` too.
>
> That said, you want to instead:
>
> ```diff
> --- a/offload/DeviceRTL/CMakeLists.txt
> +++ b/offload/DeviceRTL/CMakeLists.txt
> @@ -132,7 +132,7 @@ function(compileDev
jhuber6 wrote:
> Yeah, appending `-march=` seems to work.
Is this a functional work-around for now?
```diff
diff --git a/offload/DeviceRTL/CMakeLists.txt b/offload/DeviceRTL/CMakeLists.txt
index cce360236960..277ad9816411 100644
--- a/offload/DeviceRTL/CMakeLists.txt
+++ b/offload/DeviceRTL/CMak
jhuber6 wrote:
> This change broke building with GCC set as the C++ compiler:
>
> ```
> FAILED: libomptarget-nvptx.bc
> : && /usr/lib/ccache/bin/x86_64-pc-linux-gnu-g++ -O2 -pipe -march=native
> -Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs
> --target=nvptx64-nvidia-cuda -r -nostdlib
https://github.com/jhuber6 approved this pull request.
Makes sense, since this is only for these call arguments which are handled in
all cases now I presume.
https://github.com/llvm/llvm-project/pull/127528
___
cfe-commits mailing list
cfe-commits@lis
@@ -162,6 +162,62 @@ __gpu_shuffle_idx_u64(uint64_t __lane_mask, uint32_t
__idx, uint64_t __x,
((uint64_t)__gpu_shuffle_idx_u32(__lane_mask, __idx, __lo, __width));
}
+// Returns a bitmask marking all lanes that have the same value of __x.
+_DEFAULT_FN_ATTRS static _
@@ -8336,12 +8336,11 @@ static bool verifyValidIntegerConstantExpr(Sema &S,
const ParsedAttr &Attr,
/// match one of the standard Neon vector types.
static void HandleNeonVectorTypeAttr(QualType &CurType, const ParsedAttr &Attr,
Sema &S, Ve
@@ -0,0 +1,6 @@
+// RUN: %clang -fopenmp --offload-arch=sm_90 -nocudalib -target
aarch64-unknown-linux-gnu -c -Xclang -verify %s
jhuber6 wrote:
Seems CUDA used to have a test for this but it was removed for some reason? I
would just stash it in `SemaOpenMP` or
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/126956
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/127439
___
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/127504
Summary:
These helpers are very useful but currently absent. They allow the user
to get a bitmask representing the matches within the warp. I have made
an executive decision to drop the `predicate` return from `m
jhuber6 wrote:
The test you added doesn't seem to pass. You can run it locally with `llvm-lit
/path/to/your/test -v`.
https://github.com/llvm/llvm-project/pull/127439
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
@@ -1109,6 +1109,11 @@ class Triple {
Env == llvm::Triple::EABIHF;
}
+ /// Tests if the target represents a device which can be offloaded to.
+ bool isOffloadingTarget() const {
+return isAMDGPU() || isNVPTX() || isSPIRV();
+ }
jhuber6 wrot
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/127439
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/126956
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/126956
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -92,6 +92,14 @@ LIBC_INLINE uint32_t shuffle(uint64_t lane_mask, uint32_t
idx, uint32_t x,
return __gpu_shuffle_idx_u32(lane_mask, idx, x, width);
}
+LIBC_INLINE uint64_t match_any(uint64_t lane_mask, uint32_t x) {
+ return __gpu_match_any_u32(lane_mask, x);
+}
+
+LIBC_
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/127504
>From 821ad9e2fb7c3a6b39bc0b782342dcfd9c1b32c6 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 17 Feb 2025 09:04:03 -0600
Subject: [PATCH] [Clang] Add handlers for 'match_any' and 'match_all' to
`gpuintr
jhuber6 wrote:
The fix will need to be backported, but I don't think this fixed it all the way
so we'll need another follow-up.
https://github.com/llvm/llvm-project/pull/127528
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
jhuber6 wrote:
The reproducer I posted above still crashes, just in a different place.
```
clang-21:
/home/jhuber/Documents/llvm/llvm-project/llvm/lib/IR/Instructions.cpp:744: void
llvm::CallInst::init(llvm::FunctionType*, llvm::Value*,
llvm::ArrayRef,
llvm::ArrayRef >, const llvm::Twine&):
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/127703
Summary:
The scan operation implemented here only works if there are contiguous
ones in the executation mask that can be used to propagate the result.
There are two solutions to this, one is to enter 'whole-wave-
https://github.com/jhuber6 milestoned
https://github.com/llvm/llvm-project/pull/127504
___
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/127703
>From bf81a9280b0fda28862fb56f633614ce9bae9840 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 18 Feb 2025 15:08:05 -0600
Subject: [PATCH] [Clang] Fix cross-lane scan when given divergent lanes
Summary:
jhuber6 wrote:
/cherry-pick
https://github.com/llvm/llvm-project/commit/9a584b07d7c29cec65bb446782c4af72e6d8
https://github.com/llvm/llvm-project/pull/127504
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
https://github.com/jhuber6 milestoned
https://github.com/llvm/llvm-project/pull/127703
___
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/127703
>From ba202eaabaa49d17a53e0be7f8b08efb7d469a2c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 18 Feb 2025 15:08:05 -0600
Subject: [PATCH] [Clang] Fix cross-lane scan when given divergent lanes
Summary:
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/126143
>From ce6029a3de4e330de88da468f20cb96372b99d43 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Feb 2025 15:54:19 -0600
Subject: [PATCH] [OpenMP] Remove 'libomptarget.devicertl.a' fatbinary and use
stat
@@ -162,6 +162,62 @@ __gpu_shuffle_idx_u64(uint64_t __lane_mask, uint32_t
__idx, uint64_t __x,
((uint64_t)__gpu_shuffle_idx_u32(__lane_mask, __idx, __lo, __width));
}
+// Returns a bitmask marking all lanes that have the same value of __x.
+_DEFAULT_FN_ATTRS static _
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/127504
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -259,6 +259,26 @@ Value *readX18AsPtr(CodeGenFunction &CGF) {
return CGF.Builder.CreateIntToPtr(X18, CGF.Int8PtrTy);
}
+llvm::Constant *CodeGenModule::getDeviceLibFunction(const FunctionDecl *FD,
+unsigned BuiltinID) {
+
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/129347
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
https://github.com/llvm/llvm-project/pull/130285 I'll see if this makes CI
happy, thanks so much for your diagnosis.
https://github.com/llvm/llvm-project/pull/130248
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/130177
>From 728e1bd9cccb56a0acaf5abb35fe64cacc5b4ae9 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Mar 2025 15:08:25 -0600
Subject: [PATCH 1/4] [Clang] Treat `ext_vector_type` as a regular type
attribute
jhuber6 wrote:
> I'm not super thrilled about NOT having to introduce a type name, I'm not
> looking forward to the exciting world of `void foo(int
> __attribute__((ext_vector_type(4))) x)` replacing `void foo(int4 x)`.
This makes introducing a type name easier because you can use `using` with
jhuber6 wrote:
I suppose I could try to introduce the RegularKeyword usage that the other
patch used? That would make it like `__ext_vector_type` I think. (And honestly,
while I'm at it, do you think we could drop the `ext`?)
https://github.com/llvm/llvm-project/pull/130177
___
Author: Joseph Huber
Date: 2025-03-07T13:55:39-06:00
New Revision: fefb6858da42053268b53c07aff8e1cf84dc1ada
URL:
https://github.com/llvm/llvm-project/commit/fefb6858da42053268b53c07aff8e1cf84dc1ada
DIFF:
https://github.com/llvm/llvm-project/commit/fefb6858da42053268b53c07aff8e1cf84dc1ada.diff
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/130285
>From d39b407a6ae2000f91a345c18cb710647b86c1c8 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 7 Mar 2025 07:54:50 -0600
Subject: [PATCH 1/3] [LinkerWrapper] Try to fix testing on Windows
Summary:
Thanks
@@ -599,9 +599,11 @@ Expected writeOffloadFile(const OffloadFile
&File) {
StringRef Prefix =
sys::path::stem(Binary.getMemoryBufferRef().getBufferIdentifier());
-
- auto TempFileOrErr = createOutputFile(
- Prefix + "-" + Binary.getTriple() + "-" + Binary.getArch
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/130177
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> > I think people are just confusing what `-flto` means when put on a link job.
>
> Including me. :)
>
> Apologies for my ignorance, what does this do and why do we want it? It
> allows for some (LTO-related?) flags to be forwarded/handled correctly?
The clang driver is very c
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/129118
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Joseph Huber
Date: 2025-03-07T10:39:09-06:00
New Revision: 3ed4daf9a749fe8590ad291f63fabce48fb4135f
URL:
https://github.com/llvm/llvm-project/commit/3ed4daf9a749fe8590ad291f63fabce48fb4135f
DIFF:
https://github.com/llvm/llvm-project/commit/3ed4daf9a749fe8590ad291f63fabce48fb4135f.diff
@@ -62,11 +62,11 @@
// STATIC: Found undefined HIP fatbin symbol: __hip_fatbin_[[ID2:[0-9a-f]+]]
// STATIC: Found undefined HIP gpubin handle symbol:
__hip_gpubin_handle_[[ID1]]
// STATIC: Found undefined HIP gpubin handle symbol:
__hip_gpubin_handle_[[ID2]]
-// STATIC: "{{.*
jhuber6 wrote:
> I think vector types as a type attribute are reasonable, at least at first
> blush. However, if we're talking about redesigning the feature to expose it
> in a more natural way, we should consider what proposals are in front of the
> C and C++ standards committees.
This mostl
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/130285
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -599,9 +599,10 @@ Expected writeOffloadFile(const OffloadFile
&File) {
StringRef Prefix =
sys::path::stem(Binary.getMemoryBufferRef().getBufferIdentifier());
-
- auto TempFileOrErr = createOutputFile(
- Prefix + "-" + Binary.getTriple() + "-" + Binary.getArch
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/130285
>From d39b407a6ae2000f91a345c18cb710647b86c1c8 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 7 Mar 2025 07:54:50 -0600
Subject: [PATCH 1/2] [LinkerWrapper] Try to fix testing on Windows
Summary:
Thanks
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/130177
>From 728e1bd9cccb56a0acaf5abb35fe64cacc5b4ae9 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Mar 2025 15:08:25 -0600
Subject: [PATCH 1/8] [Clang] Treat `ext_vector_type` as a regular type
attribute
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/130285
Summary:
Thanks to @Meinersbur for finding this. The `:` character used in AMD's
target-id's is invalid on windows. This patch replaces them with `_`.
>From d39b407a6ae2000f91a345c18cb710647b86c1c8 Mon Sep 17 0
jhuber6 wrote:
> > but it turns on LTO by default right?
>
> This is very much how I read that patch too. Maybe the flag names and
> comments are a bit misleading here.
I think people are just confusing what `-flto` means when put on a link job.
https://github.com/llvm/llvm-project/pull/12911
jhuber6 wrote:
@erichkeane Is this good to go now? CI's green and I reverted the attribute
back to your initial approval.
https://github.com/llvm/llvm-project/pull/130177
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
@@ -599,9 +599,10 @@ Expected writeOffloadFile(const OffloadFile
&File) {
StringRef Prefix =
sys::path::stem(Binary.getMemoryBufferRef().getBufferIdentifier());
-
- auto TempFileOrErr = createOutputFile(
- Prefix + "-" + Binary.getTriple() + "-" + Binary.getArch
jhuber6 wrote:
@Meinersbur Do you have a good guess why this fails on Windows? It's difficult
to triage without a windows machine.
https://github.com/llvm/llvm-project/pull/130248
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.l
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/129927
___
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/130177
>From 728e1bd9cccb56a0acaf5abb35fe64cacc5b4ae9 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Mar 2025 15:08:25 -0600
Subject: [PATCH 1/7] [Clang] Treat `ext_vector_type` as a regular type
attribute
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/130177
>From 728e1bd9cccb56a0acaf5abb35fe64cacc5b4ae9 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Mar 2025 15:08:25 -0600
Subject: [PATCH 1/6] [Clang] Treat `ext_vector_type` as a regular type
attribute
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/130177
>From 728e1bd9cccb56a0acaf5abb35fe64cacc5b4ae9 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Mar 2025 15:08:25 -0600
Subject: [PATCH 1/5] [Clang] Treat `ext_vector_type` as a regular type
attribute
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/129917
___
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/130177
>From 728e1bd9cccb56a0acaf5abb35fe64cacc5b4ae9 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Mar 2025 15:08:25 -0600
Subject: [PATCH 1/7] [Clang] Treat `ext_vector_type` as a regular type
attribute
jhuber6 wrote:
I don't know why the documentation build keeps failing, just says it's missing
a header, but this one looks like all the other ones.
https://github.com/llvm/llvm-project/pull/130177
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/130177
>From 728e1bd9cccb56a0acaf5abb35fe64cacc5b4ae9 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Mar 2025 15:08:25 -0600
Subject: [PATCH 1/6] [Clang] Treat `ext_vector_type` as a regular type
attribute
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/130285
___
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/130177
>From 728e1bd9cccb56a0acaf5abb35fe64cacc5b4ae9 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Mar 2025 15:08:25 -0600
Subject: [PATCH 1/7] [Clang] Treat `ext_vector_type` as a regular type
attribute
Author: Joseph Huber
Date: 2025-03-05T19:15:23-06:00
New Revision: 12c5a46c300eedb6cafc68b987abb9c1fa913e96
URL:
https://github.com/llvm/llvm-project/commit/12c5a46c300eedb6cafc68b987abb9c1fa913e96
DIFF:
https://github.com/llvm/llvm-project/commit/12c5a46c300eedb6cafc68b987abb9c1fa913e96.diff
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/130177
Summary:
This attribute is mostly borrowed from OpenCL, but is useful in general
for accessing the LLVM vector types. Previously the only way to use it
was through typedefs. This patch changes that to allow use a
@@ -78,7 +78,7 @@ typedef int __attribute__((ext_vector_type(0))) e4;
// expected-e
// no support for vector enum type
enum { e_2 } x3 __attribute__((vector_size(64))); // expected-error {{invalid
vector element type}}
-int x4 __attribute__((ext_vector_type(64
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/130177
>From 728e1bd9cccb56a0acaf5abb35fe64cacc5b4ae9 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Mar 2025 15:08:25 -0600
Subject: [PATCH 1/2] [Clang] Treat `ext_vector_type` as a regular type
attribute
@@ -78,7 +78,7 @@ typedef int __attribute__((ext_vector_type(0))) e4;
// expected-e
// no support for vector enum type
enum { e_2 } x3 __attribute__((vector_size(64))); // expected-error {{invalid
vector element type}}
-int x4 __attribute__((ext_vector_type(64
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/130177
>From 728e1bd9cccb56a0acaf5abb35fe64cacc5b4ae9 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Mar 2025 15:08:25 -0600
Subject: [PATCH 1/3] [Clang] Treat `ext_vector_type` as a regular type
attribute
@@ -107,7 +107,7 @@ RawAddress CodeGenFunction::CreateTempAlloca(llvm::Type
*Ty, CharUnits Align,
// be different from the type defined by the language. For example,
// in C++ the auto variables are in the default address space. Therefore
// cast alloca to the default ad
@@ -614,6 +614,20 @@ void
AMDGPUTargetCodeGenInfo::setCUDAKernelCallingConvention(
FT, FT->getExtInfo().withCallingConv(CC_OpenCLKernel));
}
+/// Return IR struct type for rtinfo struct in rocm-device-libs used for device
+/// enqueue.
+///
+/// ptr addrspace(1) kernel_
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/126143
>From 952c2b4a49eb2d8e2ffa00dd94032d37b0d4302b Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 6 Feb 2025 15:54:19 -0600
Subject: [PATCH] [OpenMP] Remove 'libomptarget.devicertl.a' fatbinary and use
stat
https://github.com/jhuber6 approved this pull request.
LG from the clang driver side. I'll let the SPIR-V experts determine the rest.
https://github.com/llvm/llvm-project/pull/129545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/129118
Summary:
Previously we turned this off, but that led to a regression in some of
the option handling. I would argue that handling LTO by default was
incorrect bheavior, but for AMDGPU people were used to this defa
jhuber6 wrote:
> We do have some framework teams that are still using non-LTO (or non-gpu-rdc)
> build.
This doesn't force that, adding `-flto` just informs the compiler to forward
certain flags to the linker.
https://github.com/llvm/llvm-project/pull/129118
__
jhuber6 wrote:
> The motivation came from CUDA cccl code containing __builtin_logb and
> __builtin_scalbn and being able to handle them.
In my ideal world, unhandled builtins would be lowered before the linker and
we'd have a working library called `libm.a` that matches the platform.
https://
jhuber6 wrote:
> I would have preferred to do the overloads in the target specific header
> file, but __builtin_* methods couldn't be overloaded. I noticed that hip math
> header already overloads 'double logb(double)' by calling ocml version, so I
> mirrored that in clang. If there is better
https://github.com/jhuber6 approved this pull request.
LG
https://github.com/llvm/llvm-project/pull/131141
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/131134
___
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.
LG
https://github.com/llvm/llvm-project/pull/131134
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 commented:
Should probably just be called `spirvintrin.h` unless there's something that
significantly distinguishes this from the 32-bit counterpart. (Same reason it's
`nvptxintrin` and not `nvptx64intrin`.
https://github.com/llvm/llvm-project/pull/131164
___
jhuber6 wrote:
The OpenMP runtime doesn't know how to handle `generic` ISAs right?
https://github.com/llvm/llvm-project/pull/130963
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> CC @jdoerfert @ye-luo Once this is merged, ROCm 6.3 will be needed to run any
> program compiled for AMDGPU.
Unless you pass `-mcode-object-version=5` right?
https://github.com/llvm/llvm-project/pull/130963
___
cfe-commits mailing li
jhuber6 wrote:
> not everything should end up in Clang, even though it is individually
> "convenient"
We should at least have some builtins for those SPIR-V intrinsics you listed. I
think right now we only have `reflect`.
https://github.com/llvm/llvm-project/pull/131190
__
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/131190
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -263,8 +256,4 @@ _DEFAULT_FN_ATTRS static __inline__ void
__gpu_thread_suspend(void) {
_Pragma("omp end declare variant");
_Pragma("omp end declare target");
-#if !defined(__cplusplus)
-_Pragma("pop_macro(\"bool\")");
jhuber6 wrote:
Where did this go?
ht
jhuber6 wrote:
> Clang raises a lot of exciting errors for spirv-- about vulcan environments
> and I don't really know the distinction between the two - if 32 bit spirv
> turns out to be a workable thing it should go down the same code path, with
> `ifdef SPIRV || SPIRV64` and a file rename. I
@@ -4770,6 +4770,35 @@ def GetDeviceSideMangledName : LangBuiltin<"CUDA_LANG"> {
let Prototype = "char const*(...)";
}
+// GPU intrinsics
+class GPUBuiltin : Builtin {
jhuber6 wrote:
We need a way to make these only emitted on 'gpu' compilations.
https://g
@@ -0,0 +1,501 @@
+//===- LowerGPUIntrinsic.cpp
--===//
+//
+// 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: Ap
https://github.com/jhuber6 commented:
So this is basically a serialization of the headers in `gpuintrin.h` as IR?
I'll need to defer to the people more familiar with the backend / IR layer but
I have a few comments.
https://github.com/llvm/llvm-project/pull/131190
_
jhuber6 wrote:
> > > not everything should end up in Clang, even though it is individually
> > > "convenient"
> >
> >
> > We should at least have some builtins for those SPIR-V intrinsics you
> > listed. I think right now we only have `reflect`.
>
> Probably, I think there's a sense that in
@@ -32,6 +32,31 @@ _Pragma("push_macro(\"bool\")");
#define bool _Bool
#endif
+_Pragma("omp begin declare target device_type(nohost)");
+_Pragma("omp begin declare variant match(device = {kind(gpu)})");
+
+// Forward declare a few functions for the implementation header.
+
+//
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/129917
Summary:
The `-Wglobal-constructors` option is useful for restricting the usage
of global constructors / destructors. However, it currently ignores the
attributes that introduce global constructors, meaning that
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/129927
Summary:
These require `+ptx` features to be set even though they're guarded by
the `__nvvm_reflect`. Rather than figure out how to hack around that
with the `target` attribute I'm just going to disable it for 'g
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/129917
>From 2ee71790f4963147bf15805697a250f9134b7fe6 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 5 Mar 2025 13:27:19 -0600
Subject: [PATCH] [Clang] Make '-Wglobal-constructors` work on the GNU
attributes
https://github.com/jhuber6 approved this pull request.
Thanks
https://github.com/llvm/llvm-project/pull/126956
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -179,8 +179,10 @@ __gpu_shuffle_idx_u64(uint64_t __lane_mask, uint32_t
__idx, uint64_t __x,
_DEFAULT_FN_ATTRS static __inline__ uint64_t
__gpu_match_any_u32(uint64_t __lane_mask, uint32_t __x) {
// Newer targets can use the dedicated CUDA support.
- if (__CUDA_ARCH__ >=
2501 - 2600 of 2696 matches
Mail list logo
