https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/147823
___
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/147823
>From 7f9ea74bfb79084bc4000b22acda68e9e9c996b9 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 9 Jul 2025 15:32:57 -0500
Subject: [PATCH] [Clang] Extract offloading code from static libs with
'offload-ar
@@ -263,3 +264,37 @@
// HIP: while.end:
// HIP-NEXT: ret void
// HIP-NEXT: }
+
+// RUN: clang-offload-packager -o %t.out
--image=file=%t.elf.o,kind=sycl,triple=spirv64-unknown-unknown,arch=generic
+// RUN: %clang -cc1 %s -triple x86_64-unknown-linux-gnu -emit-obj -o %t.
jhuber6 wrote:
This broke the NVPTX build which makes the `Offload.cmake` cache file that we
recommend people use no longer work. I'm not sure why but we're no longer
passing `-nostdlibinc` and other flags.
https://github.com/llvm/llvm-project/pull/134893
__
jhuber6 wrote:
> > but we now assume that if the user specified --offload-arch= on the link
> > job, they definitely want that architecture to be used if it exists.
>
> That would be my assumption, too. Do we currently just ignore
> `--offload-arch=` for the linking phase?
>
> With the patch,
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/147558
Summary:
These commands both do the same thing and behave like the same tool.
Now, the `nvptx-arch` and `amdgpu-arch` tools cause it to only emit
architectures for that name.
>From a24b068349265b2741763711afdcb
https://github.com/jhuber6 commented:
Agreed that this should be a resource directory thing, we made the mistake of
not doing that in OpenMP until I moved it to just a normal lib.
https://github.com/llvm/llvm-project/pull/146503
___
cfe-commits mailin
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/146594
___
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/146594
>From 072e1d14c324ab501319d967bafe2588fff2d233 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 3 Feb 2025 12:46:27 -0600
Subject: [PATCH] [Clang] Introduce '--offload-targets' for `-fopenmp-targets`
Summ
@@ -1138,6 +1138,10 @@ def fno_convergent_functions : Flag<["-"],
"fno-convergent-functions">,
// Common offloading options
let Group = offload_Group in {
+def offload_targets_EQ : CommaJoined<["--"], "offload-targets=">,
jhuber6 wrote:
Yeah, I'm not sure if
jhuber6 wrote:
> So your users today are building for generic AMDGPU but using builtins that
> are only available on a specific processor release? Presumably that code is
> protected _somehow_ and their programs are not simply crashing at runtime. Is
> that something you'd be able to leverage
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/146687
___
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/146687
Summary:
This didn't use the built-in 'CommaJoined' feature for arguments and
parsed out the strings manually. This patch simplifies this by just
using the present functionality.
>From 7d5369ae9268eff3aa08f2ef9
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/146594
>From 8db1344221d36408663b684cd5217a112bbe26fe Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 3 Feb 2025 12:46:27 -0600
Subject: [PATCH 1/2] [Clang] Introduce '--offload-targets' for
`-fopenmp-targets`
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/143909
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> There was an attempt to add universal GPU builtins in #131190 . Between these
> 2 patches I prefer the current approach as it adds more common functionality
> for all vendors. Yet let me tag folks that have participated in a discussion
> of the mentioned PR.
I would love to h
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/146594
>From 8db1344221d36408663b684cd5217a112bbe26fe Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 3 Feb 2025 12:46:27 -0600
Subject: [PATCH 1/2] [Clang] Introduce '--offload-targets' for
`-fopenmp-targets`
@@ -1138,6 +1138,10 @@ def fno_convergent_functions : Flag<["-"],
"fno-convergent-functions">,
// Common offloading options
let Group = offload_Group in {
+def offload_targets_EQ : Joined<["--"], "offload-targets=">,
jhuber6 wrote:
Right, forgot that, thanks
@@ -116,6 +116,8 @@ def err_drv_cuda_host_arch : Error<
"unsupported architecture '%0' for host compilation">;
def err_drv_mix_cuda_hip : Error<
"mixed CUDA and HIP compilation is not supported">;
+def err_drv_mix_offload : Error<
jhuber6 wrote:
Oh that's
jhuber6 wrote:
> I see. That makes sense. Worth a release note item.
This is just an alias, doesn't do what I want it to do yet. Struggling with how
to maintain current semantics without hacking spaghetti code all over the
place. Figured this was something I could pull out to make that smoothe
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/146594
>From c8e633a2384760c2c6d5b56f3de6cdf9b8ebde7e Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 3 Feb 2025 12:46:27 -0600
Subject: [PATCH] [Clang] Introduce '--offload-targets' for `-fopenmp-targets`
Summ
jhuber6 wrote:
> Why not stick with `--offload-arch` for generic use? I'm not really sure
> about the motivation.
This is the main problem I have with a lot of the offloading infrastructure. As
far as I see it `--offload-arch=` is intended to behave like the `-mcpu` value
but it's pulling dou
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/146594
Summary:
This patch is mostly an NFC that renames the existing `-fopenmp-targets`
into `--offload-targets`. Doing this early to simplify a follow-up patch
that will hopefully allow this syntax to be used more gen
jhuber6 wrote:
High liklihood that I'll need something similar for my GPU libraries so I'd
prefer something not explicitly tied to SPIR-V.
https://github.com/llvm/llvm-project/pull/134016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https:/
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/146342
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -3694,6 +3710,10 @@ void CompilerInvocationBase::GenerateLangArgs(const
LangOptions &Opts,
GenerateArg(Consumer, OPT_pic_is_pie);
for (StringRef Sanitizer : serializeSanitizerKinds(Opts.Sanitize))
GenerateArg(Consumer, OPT_fsanitize_EQ, Sanitizer);
+if (
@@ -4002,6 +4022,24 @@ bool CompilerInvocation::ParseLangArgs(LangOptions
&Opts, ArgList &Args,
parseSanitizerKinds("-fsanitize=", Args.getAllArgValues(OPT_fsanitize_EQ),
Diags, Opts.Sanitize);
+if (const Arg *A = Args.getLastArg(options::OPT_e
@@ -3679,6 +3679,22 @@ static StringRef GetInputKindName(InputKind IK) {
llvm_unreachable("unknown input language");
}
+static StringRef getExceptionHandlingName(unsigned EHK) {
+ switch (static_cast(EHK)) {
+ case LangOptions::ExceptionHandlingKind::None:
+ default:
+
https://github.com/jhuber6 approved this pull request.
Seems reasonable to me, some nits.
https://github.com/llvm/llvm-project/pull/146342
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commi
jhuber6 wrote:
> We could allow `__builtin_processor_is` as an alternative name for that
> builtin if folks feel weird about having "cpu" in the name for a GPU target.
We already use `-mcpu=gfx942` for targeting the GPU processor so I don't think
it makes a huge difference. I've never heard of
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/145799
>From 6ca9607d8e75217744b4818465723e5b5f02db53 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 25 Jun 2025 17:21:21 -0500
Subject: [PATCH 1/3] [Clang] Determine offloading architectures at Toolchain
crea
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/145799
___
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/145799
>From 904f4b8f5635b99fefa4b8a684b8ee2ae2362179 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 25 Jun 2025 17:21:21 -0500
Subject: [PATCH] [Clang] Determine offloading architectures at Toolchain
creation
https://github.com/jhuber6 approved this pull request.
The comma operator strikes again, thanks.
https://github.com/llvm/llvm-project/pull/145900
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cf
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/145799
>From 6ca9607d8e75217744b4818465723e5b5f02db53 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 25 Jun 2025 17:21:21 -0500
Subject: [PATCH] [Clang] Determine offloading architectures at Toolchain
creation
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/145549
>From 205affa55b78944f9807fc10b9c592407c6c07be Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 24 Jun 2025 11:45:00 -0500
Subject: [PATCH 1/2] [Clang] Clean up OpenMP offload toolchain generation
Summary
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/145549
___
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/145549
Summary:
Small cleanup prior to some larger changes in this area. I want to move
the offload arch detection to be done solely here.
This might change the order the targets show up in but shouldn't affect
anythin
Miguel =?utf-8?q?Cárdenas?= ,
Miguel =?utf-8?q?Cárdenas?= ,
Miguel =?utf-8?q?Cárdenas?=
Message-ID:
In-Reply-To:
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/145365
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
Miguel =?utf-8?q?C=C3=A1rdenas?= ,
Miguel =?utf-8?q?C=C3=A1rdenas?= ,
Miguel =?utf-8?q?C=C3=A1rdenas?=
Message-ID:
In-Reply-To:
https://github.com/jhuber6 approved this pull request.
Yeah, usually easier to do a force push if you plan on doing a rebase.
https://github.com/llvm/llvm-project/pu
Miguel =?utf-8?q?C=C3=A1rdenas?= ,
Miguel =?utf-8?q?C=C3=A1rdenas?=
Message-ID:
In-Reply-To:
jhuber6 wrote:
Can you see why the CI is unhappy?
https://github.com/llvm/llvm-project/pull/145200
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
Miguel =?utf-8?q?Cárdenas?=
Message-ID:
In-Reply-To:
https://github.com/jhuber6 approved this pull request.
So, this is probably a little weird since we now have two ways this is parsed.
One through the LLVM commandline interface and another here as the command
options interface. The reason
@@ -341,11 +341,23 @@ Expected> createLTO(const
ArgList &Args) {
Conf.CPU = Args.getLastArgValue(OPT_arch);
Conf.Options = codegen::InitTargetOptionsFromCodeGenFlags(Triple);
- Conf.RemarksFilename = RemarksFilename;
- Conf.RemarksPasses = RemarksPasses;
- Conf.Remarks
@@ -72,6 +72,25 @@ def : Joined<["--", "-"], "plugin-opt=emit-llvm">,
Flags<[WrapperOnlyOption]>, Alias;
def : Joined<["--", "-"], "plugin-opt=emit-asm">,
Flags<[WrapperOnlyOption]>, Alias;
+
+def opt_remarks_filename : Separate<["--"], "opt-remarks-filename">,
+ Flags<[Wr
https://github.com/jhuber6 approved this pull request.
Bit of a hack it seems, but better than it being broken.
https://github.com/llvm/llvm-project/pull/144914
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/144570
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -417,3 +417,15 @@ void HIPAMDToolChain::checkTargetID(
getDriver().Diag(clang::diag::err_drv_bad_target_id)
<< *PTID.OptionalTargetID;
}
+
+SPIRVAMDToolChain::SPIRVAMDToolChain(const Driver &D,
+ const llvm::Triple &Triple,
+
jhuber6 wrote:
> > `llvm.compiler.used` global uses AS(0) which makes SPIR-V unhappy, but with
> > this global it's AS(4) which makes it happy. Either way, this should be
> > fixed.
>
> llvm.used and llvm.compiler.used should universally use addrspace(0) and
> SPIRV should be fixed to not bre
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/144605
___
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/144605
Summary:
The logic here is flawed, it was only intended to apply to the CPU case
where we use the linker passed in on the command line. This was falsely
applying to SPIR-V which caused issues.
>From a0a041b7904
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/144570
___
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/144576
>From 94ad34a699173fe6b62614874952ca5cfe98f471 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 17 Jun 2025 12:58:14 -0500
Subject: [PATCH] [Clang] Add standalone AMDGPU SPIR-V toolchain
Summary:
The AMDG
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/144576
>From 92db44cf46098f9171b06d0251b632eb1ff6d5e6 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 17 Jun 2025 12:58:14 -0500
Subject: [PATCH] [Clang] Add standalone AMDGPU SPIR-V toolchain
Summary:
The AMDG
@@ -417,3 +417,17 @@ void HIPAMDToolChain::checkTargetID(
getDriver().Diag(clang::diag::err_drv_bad_target_id)
<< *PTID.OptionalTargetID;
}
+
+SPIRVAMDToolChain::SPIRVAMDToolChain(const Driver &D,
+ const llvm::Triple &Triple,
+
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/144576
Summary:
The AMDGPU toolchain uses a different set of tools than the standard
SPIR-V toolchain. The linker wrapper prefers to invoke a linker via a
clang toolchain. To make that work we introduce
`--target=spirv6
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/144570
Summary:
This is a weird point of divergence, which is also apparently critical
for SPIR-V compilation not failing? Somehow if we don't emit this global
than the `llvm.compiler.used` global uses AS(0) which makes
@@ -9249,8 +9249,20 @@ void LinkerWrapper::ConstructJob(Compilation &C, const
JobAction &JA,
// Add the linker arguments to be forwarded by the wrapper.
CmdArgs.push_back(Args.MakeArgString(Twine("--linker-path=") +
LinkCommand->getEx
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/143964
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -310,8 +310,8 @@ Error relocateOffloadSection(const ArgList &Args, StringRef
Output) {
// Remove the old .llvm.offloading section to prevent further linking.
ObjcopyArgs.emplace_back("--remove-section");
ObjcopyArgs.emplace_back(".llvm.offloading");
- for (StringRef
https://github.com/jhuber6 approved this pull request.
Looks good. Thanks for digging into this, guess I forgot to update the
relocatable bit when I made that change.
https://github.com/llvm/llvm-project/pull/143964
___
cfe-commits mailing list
cfe-co
@@ -947,11 +954,18 @@ bool InstrLowerer::lower() {
if (!ContainsProfiling && !CoverageNamesVar)
return MadeChange;
+ // Cached info for generating delayed offset calculations
+ // This is only relevant on NVPTX targets
+ SmallVector Kernels;
+ SmallVector ValueSites;
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/134016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,21 @@
+// REQUIRES: amdgpu-registered-target
+// REQUIRES: spirv-registered-target
+// RUN: %clang_cc1 -fsyntax-only -verify -triple amdgcn -Wno-unused-value %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spirv64-amd-amdhsa
-Wno-unused-value %s
+// RUN: %clang_cc
https://github.com/jhuber6 commented:
This looks generally good to me, but I'll let the clang code owners make the
final decision.
https://github.com/llvm/llvm-project/pull/134016
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.l
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/143490
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/143432
___
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/143432
This breaks a lot of new driver HIP compilation. We should probably
revert this for now until we can make a fixed version.
```c++
static __global__ void print() { printf("%s\n", "foo"); }
void b();
int main()
jhuber6 wrote:
> LGTM but I'm never sure who owns this aspect of NVPTX. @Artem-B, @jhuber6 ?
I work at AMD and don't really know much about OpenCL.
https://github.com/llvm/llvm-project/pull/143331
___
cfe-commits mailing list
cfe-commits@lists.llvm.or
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/125744
___
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/125744
>From ce7701b7c95ee1e59c7942b23833a7a7336abfb7 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 4 Feb 2025 12:06:34 -0600
Subject: [PATCH] Reapply "[AMDGPU] Use the AMDGPUToolChain when targeting
C/C++ di
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/142021
Summary:
This patch identifies the CUDA path that clang used and forwards it to
the linker wrapper. This should make sure that we're using a consistent
CUDA path, but the behavior should be the same for normal us
https://github.com/jhuber6 approved this pull request.
The `.bc` file for AMDGPU is unused, I'd imagine SPIR-V is as well since its
compilation flow is like AMDGPU.
https://github.com/llvm/llvm-project/pull/141855
___
cfe-commits mailing list
cfe-comm
@@ -72,7 +72,7 @@ else()
# Note that we check this later (for both build types) but we can provide a
# more useful error message when built in-tree. We assume that LLVM tools are
# always available so don't warn here.
- if( NOT clang IN_LIST LLVM_ENABLE_PROJECTS )
+ if(
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/141142
>From 07caec33a1113602f3d6ba79357edeae6b66647c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 22 May 2025 16:21:34 -0500
Subject: [PATCH] [OpenMP] Fix atomic compare handling with overloaded
operators
@@ -12062,32 +12154,56 @@ bool
OpenMPAtomicCompareCaptureChecker::checkForm3(IfStmt *S,
X = BO->getLHS();
D = BO->getRHS();
- auto *Cond = dyn_cast(S->getCond());
- if (!Cond) {
+ if (auto *Cond = dyn_cast(S->getCond())) {
+C = Cond;
+if (Cond->getOpcode() != B
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/141142
>From f2c18ba64744320a8e2a63938b17137a1b6e74d7 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 22 May 2025 16:21:34 -0500
Subject: [PATCH] [OpenMP] Fix atomic compare handling with overloaded
operators
@@ -991,3 +991,34 @@ int mixed() {
// expected-note@+1 {{in instantiation of function template specialization
'mixed' requested here}}
return mixed();
}
+
+#ifdef OMP51
+struct U {};
+struct U operator<(U, U);
+struct U operator>(U, U);
+struct U operator==(U, U);
+
+templ
@@ -12062,32 +12154,56 @@ bool
OpenMPAtomicCompareCaptureChecker::checkForm3(IfStmt *S,
X = BO->getLHS();
D = BO->getRHS();
- auto *Cond = dyn_cast(S->getCond());
- if (!Cond) {
+ if (auto *Cond = dyn_cast(S->getCond())) {
+C = Cond;
+if (Cond->getOpcode() != B
jhuber6 wrote:
> I'll need to look into that - maybe we can talk offline. Since `libclc` is
> used by downstream toolchains I feel it'll be hard to significantly change
> how it's built or presented to the host. We could support two methods of
> building but that would get sticky pretty quickl
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/141142
>From a45dc43315631f28ced9cf5a14890e46e011e6d2 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 22 May 2025 16:21:34 -0500
Subject: [PATCH] [OpenMP] Fix atomic compare handling with overloaded
operators
jhuber6 wrote:
> That said, I don't believe it "works" in the way it's supposed to. It still
> grabs the host tools using `get_host_tool_path` in CMake, and custom commands
> to build with that. I take it we're supposed to use `CMAKE_C_COMPILER` as if
> we were a regular CMake project? Are we
jhuber6 wrote:
> This commit breaks a critical optimization for us. We have a project that
> compiles most of the C++26 language features to Vulkan SPIRV.
I've thought about doing that, since I've spent a few years just using normal
C++ to write GPU runtimes. The main issue right now is that t
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/141574
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
Also, if you're compiling C++26, why is it enabling OpenCL language features?
You can already do this pretty easily with `clang --target=spirv64` so long as
you're okay with using vendor intrinsic extensions in SPIR-V. That's pretty
much what the HIP support for SPIR-V does anyw
@@ -35,7 +35,7 @@ list(INSERT CMAKE_MODULE_PATH 0
# We order libraries to mirror roughly how they are layered, except that
compiler-rt can depend
# on libc++, so we put it after.
-set(LLVM_DEFAULT_RUNTIMES
"libc;libunwind;libcxxabi;pstl;libcxx;compiler-rt;openmp;offload")
+s
https://github.com/jhuber6 approved this pull request.
The changes make sense for just adding it, but does it actually work? The CMake
I've seen in `libclc` does multiple compilations and some with
`--target=amdgcn` for example, which is a little different from how the
runtimes builds handle i
https://github.com/jhuber6 approved this pull request.
Looks like a nice cleanup
https://github.com/llvm/llvm-project/pull/74178
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -11762,52 +11762,98 @@ bool
OpenMPAtomicCompareChecker::checkCondUpdateStmt(IfStmt *S,
X = BO->getLHS();
- auto *Cond = dyn_cast(S->getCond());
- if (!Cond) {
-ErrorInfo.Error = ErrorTy::NotABinaryOp;
-ErrorInfo.ErrorLoc = ErrorInfo.NoteLoc = S->getCond()->get
@@ -11762,52 +11762,98 @@ bool
OpenMPAtomicCompareChecker::checkCondUpdateStmt(IfStmt *S,
X = BO->getLHS();
- auto *Cond = dyn_cast(S->getCond());
- if (!Cond) {
-ErrorInfo.Error = ErrorTy::NotABinaryOp;
-ErrorInfo.ErrorLoc = ErrorInfo.NoteLoc = S->getCond()->get
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/141043
___
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.
We'll now be creating the XRayArgs class when we do this every time, but I
don't think it's expensive enough or done enough times to be an issue. Thanks.
https://github.com/llvm/llvm-project/pull/141043
_
jhuber6 wrote:
> but there is other comgr user expecting comgr to have -nogpuinc by default.
> changing that will cause regressions.
If `comgr` can have custom flags then you could just pass the 'do not pass
`-nogpuinc` by default' flag presumably.
https://github.com/llvm/llvm-project/pull/14
jhuber6 wrote:
> > > > Hmm, in what cases is `-nogpuinc` added when we don't actually want it?
> > > > I think we should avoid adding `-nogpuinc` if it's not needed, if
> > > > possible.
> > >
> > >
> > > comgr is the JIT compiler for HIP on ROCm. comgr uses -nogpuinc by
> > > default. Howev
jhuber6 wrote:
> > Hmm, in what cases is `-nogpuinc` added when we don't actually want it? I
> > think we should avoid adding `-nogpuinc` if it's not needed, if possible.
>
> comgr is the JIT compiler for HIP on ROCm. comgr uses -nogpuinc by default.
> However, some users of comgr need to over
jhuber6 wrote:
> > It's just the AMDGCN target without any `+features`, right? The only issue
> > I was aware of was assuming w64 when unspecified but you fixed that
> > previously.
>
> Almost, but it's problematic in several ways. The problems multiply once you
> start adding in manually spe
jhuber6 wrote:
> > The main obstacle of letting clang emit error when `--offload-arch` is not
> > specified is HIP apps using hipcc as CMAKE_CXX_COMPILER. hipcc adds -xhip
> > by default for .cpp programs. This is a known and long existing issue.
> > Another option is to have multiple `--offloa
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/139164
___
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.
Right now this checks for `libc++` less than 14. Is that still relevant
following that change?
https://github.com/llvm/llvm-project/pull/139164
___
cfe-commits mailing list
cfe-commits@lists.llvm.
jhuber6 wrote:
> @jhuber6 Was the follow-up for this backported too?
I don't remember, sorry. I think the whole thing got reverted or something?
https://github.com/llvm/llvm-project/pull/127528
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/139277
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 2085 matches
Mail list logo
