jhuber6 wrote:
> Sorry, I kind of got lost in the above discussion. Are additional changes
> required in Clang to parse builtins unsupported on the current target to make
> sure we don't break anything or is only changing the result of
> `__has_builtin` acceptable?
I believe the conclusion wa
https://github.com/jhuber6 commented:
Can we get a new test showing CUDA? CUDA uses the new driver by default so cuid
stuff will be missing there.
https://github.com/llvm/llvm-project/pull/122859
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
jhuber6 wrote:
> > I thought the new driver just got some entropy from the current source
> > file's `inode` entry? I'm not opposed, since I guess it would make sense to
> > give the user a way to override it.
>
> Sorry I did not quite get your question. Do you suggest that we need some
> opt
jhuber6 wrote:
> > > > I thought the new driver just got some entropy from the current source
> > > > file's `inode` entry? I'm not opposed, since I guess it would make
> > > > sense to give the user a way to override it.
> > >
> > >
> > > Sorry I did not quite get your question. Do you sugge
jhuber6 wrote:
> That would break rccl. We should use CUID's that work in general, including
> apps that compile the same file with different options.
Shouldn't be broken if the driver handles the CUID, I just mean that it would
work in `cc1` if not passed.
https://github.com/llvm/llvm-proj
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/120145
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
Ping
https://github.com/llvm/llvm-project/pull/120095
___
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/119091
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> @jhuber6, since I think this PR makes #119006 obsolete, should I merge that
> one while this one's still in the works, or close it?
I wouldn't say it's high priority. I would've landed this already if it weren't
for the downstream fork being so divergent this isn't an easy app
jhuber6 wrote:
@ronlieb https://gist.github.com/jhuber6/26e3fc8473a750410d2ca1db4a65918d
https://github.com/llvm/llvm-project/pull/119091
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/119091
>From 767d34a0469aa67c2c47a35bc9bff29d20ae1222 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Sat, 7 Dec 2024 13:47:23 -0600
Subject: [PATCH 1/2] [OpenMP] Use generic IR for the OpenMP DeviceRTL
Summary:
We
jhuber6 wrote:
I guess I'll see how much I favor this approach depending on how much more
difficult it is to build the DeviceRTL without OpenMP. I think the only thing
we'd miss is the `#pragma omp assumes(...)` business, which might have another
way to be emitted in LLVM/Clang?
https://githu
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/122174
___
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/122174
>From 47908c2aefc7009ccb62d4b9111fbd8d7e5ee7ad Mon Sep 17 00:00:00 2001
From: CatherineMoore
Date: Wed, 8 Jan 2025 16:33:01 -0500
Subject: [PATCH 1/2] Update OpenMPSupport.rst
---
clang/docs/OpenMPSupport.rst
@@ -343,6 +343,124 @@ implementation.
| task | nowait clause on taskwait
| :part:`partial` | parsing/sema done: D131830, D141531
|
+--+---
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/122312
___
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/123359
Summary:
This patch matches CUDA, moving the HIP compilation jobs to the new
driver by default. The old behavior will return with
`--no-offload-new-driver`. The main difference is that objects compiled
with the o
jhuber6 wrote:
> Breaking any existing HIP feature is a no-go in my opinion. Textures and
> surfaces are important to some developers.
Surfaces and textures are being phased out of CUDA as far as I can tell, so I
wasn't sure how relevant it was (since we can use `--no-offload-new-driver` as
a
jhuber6 wrote:
> > Surfaces and textures are being phased out of CUDA as far as I can tell, so
> > I wasn't sure how relevant it was (since we can use
> > `--no-offload-new-driver` as a workaround for now). CUDA clang doesn't even
> > handle surfaces, and as far as I can tell the old `cudaRegi
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/123359
>From ce890d0f8f34dc1a32edf41571f0a432e4c03586 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 17 Jan 2025 09:35:34 -0600
Subject: [PATCH] [HIP] Move HIP to the new driver by default
Summary:
This patch
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/122174
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 commented:
I've never been a fan of this type of implicit behavior, since it will change
spuriously depending on what the user wants.
I also wonder if we couldn't do something similar with ELF compression so we
don't need to manually do all this stuff.
https://githu
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/122149
>From 3329b7ae7dc6044f6563f218c65f6af7498290f0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 8 Jan 2025 12:19:53 -0600
Subject: [PATCH 1/2] [OpenMP] Allow GPUs to be targeted directly via
`-fopenmp`.
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/122149
>From 3329b7ae7dc6044f6563f218c65f6af7498290f0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 8 Jan 2025 12:19:53 -0600
Subject: [PATCH 1/3] [OpenMP] Allow GPUs to be targeted directly via
`-fopenmp`.
jhuber6 wrote:
> Do we have a clear idea on if a construct can behave in a different manner if
> it is nested in a target region?
Unsure exactly, the target regions are just outlined, so it shouldn't affect
anything on a codegen level.
https://github.com/llvm/llvm-project/pull/122149
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/122312
>From 533572c8e73c7330fe91d95428fd0189471073d8 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 9 Jan 2025 10:40:43 -0600
Subject: [PATCH] [CUDA] Move CUDA to new driver by default
Summary:
This patch upd
jhuber6 wrote:
> > All that said, there are two cases to consider wrt. the standard:
> >
> > 1. The initial device is the CPU and the code compiled here is just part of
> > a GPU library, or
> > 2. the initial device is the GPU and the code compiled here is just part of
> > the "host code".
>
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/122174
>From 47908c2aefc7009ccb62d4b9111fbd8d7e5ee7ad Mon Sep 17 00:00:00 2001
From: CatherineMoore
Date: Wed, 8 Jan 2025 16:33:01 -0500
Subject: [PATCH 1/3] Update OpenMPSupport.rst
---
clang/docs/OpenMPSupport.rst
jhuber6 wrote:
Seems to be failing for some unrelated OpenACC test.
https://github.com/llvm/llvm-project/pull/122174
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
```Warning, treated as error:
/home/runner/work/llvm-project/llvm-project/clang-build/tools/clang/docs/OpenMPSupport.rst:398:Inline
interpreted text or phrase reference start-string without end-string.
ninja: build stopped: subcommand failed.
```
>From the CI
https://github.com/l
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/122312
>From 533572c8e73c7330fe91d95428fd0189471073d8 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 9 Jan 2025 10:40:43 -0600
Subject: [PATCH 1/2] [CUDA] Move CUDA to new driver by default
Summary:
This patch
jhuber6 wrote:
> One thing that's missing is the release note. It should have an entry about
> the change and a pointer to the details and instructions on how to revert to
> the new build and, possibly a set of instructions for common use cases. E.g.
> GPU-linking a library (i.e. linking RDC-c
jhuber6 wrote:
> @jhuber6 Thanks, if you don't think we need any more reviews do you mind
> merging? I still don't have push (working on it). If not, could you please
> ping other reviewers? Thx
Sure, what's left for this to work? I'm probably going to be messing around
with the OpenMP 'Devic
@@ -2624,9 +2624,8 @@ void CGOpenMPRuntime::emitDistributeStaticInit(
emitUpdateLocation(CGF, Loc, OMP_IDENT_WORK_DISTRIBUTE);
llvm::Value *ThreadId = getThreadID(CGF, Loc);
llvm::FunctionCallee StaticInitFunction;
- bool isGPUDistribute =
- CGM.getLangOpts().Op
jhuber6 wrote:
> I think the correct place is the clang resource directory
Tough to say, the compiler resource directory is for things the compiler emits
as a part of the language, yet we don't store `libomp` there. I'd say it makes
sense, if you had `lib/clang/21/lib/amdgcn-amd-amdhsa/libcl
jhuber6 wrote:
> > Yeah, amdgcn-amd-amdhsa should be roughly equivalent to amdgcn--
>
> These are not equivalent
That's something I've been meaning to ask, the difference I know of right now
is that `amdgcn--` will not create a ROCm toolchain so we don't do any of that.
However, I don't know
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/126567
>From 4fcd51548e0f1e23f4d0082fa9f2436d5428022c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 10 Feb 2025 12:17:41 -0600
Subject: [PATCH] [Clang][NFC] Introduce `gpulib` positive flag for `nogpulib`
Sum
jhuber6 wrote:
> Marking as requesting changes so we don't accidentally land, because I've got
> questions about whether we want to go down this route.
>
> 1. GCC has `__has_builtin`, so how do they handle offloading targets? Do
> they have the same odd behavior where `__has_builtin` retur
jhuber6 wrote:
> > That's what the initial proposal / patch was, but that got reverted because
> > it broke some CUDA on Arm sources. See #121839.
>
> Yeah, but I'm suggesting that seems like a bug with CUDA on Arm sources. (But
> it also depends on how GCC behaves with offload targets; if the
Author: Joseph Huber
Date: 2025-02-14T09:56:46-06:00
New Revision: 1435c8ed95fa10a55c2f924984141e427b89c330
URL:
https://github.com/llvm/llvm-project/commit/1435c8ed95fa10a55c2f924984141e427b89c330
DIFF:
https://github.com/llvm/llvm-project/commit/1435c8ed95fa10a55c2f924984141e427b89c330.diff
jhuber6 wrote:
> > why there's a __has_builtin that's different from __can_use_builtin (or
> > whatever we name it), and I don't know that any of us have an answer for
> > that
>
> my $.02 IMO it's a side effect of heterogeneous compilation, where compiler
> has to parse source code for multi
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/126567
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> CC @jdoerfert (we don't have a CUDA maintainer, so I'm not certain who else
> to tag)
Closest is @Artem-B, there's also a few NVIDIA people floating around like
@gonzalobg.
https://github.com/llvm/llvm-project/pull/126324
___
cfe-co
jhuber6 wrote:
> What about RTTI doesn't work?
Honestly not sure what the original rationale for this was. I'm going to guess
it's either 1) slow or 2) requires libc++-abi.
https://github.com/llvm/llvm-project/pull/127082
___
cfe-commits mailing list
jhuber6 wrote:
> And just now another failure:
> https://lab.llvm.org/buildbot/#/builders/190/builds/14342
Honestly, I don't know. I'd say that it's because we don't support offloading
on Darwin, but the triple is supposed to be x64. I could probably just set the
test to unsupported for darwi
Author: Joseph Huber
Date: 2025-02-09T07:32:50-06:00
New Revision: a32efd8edc6ec5f80ffa16b3d4e52e6407d5fe99
URL:
https://github.com/llvm/llvm-project/commit/a32efd8edc6ec5f80ffa16b3d4e52e6407d5fe99
DIFF:
https://github.com/llvm/llvm-project/commit/a32efd8edc6ec5f80ffa16b3d4e52e6407d5fe99.diff
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/126143
>From 1e329fb618197df297b7431acefd89a498fb1083 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
jhuber6 wrote:
> I'm seeing our internal downstream builder hit the exact same error in this
> test, but that is building a Windows hosted compiler targeting Windows.
> Looking at our runs, it seems to have started appearing after your change
> [479ffe8](https://github.com/llvm/llvm-project/co
https://github.com/jhuber6 approved this pull request.
We've all been there
https://github.com/llvm/llvm-project/pull/126756
___
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/126143
>From 326befb8bdaafe1a2954b7aa956d26f1ec8c187f 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
jhuber6 wrote:
> Please take a look at the sanitizer buildbot failure above.
I don't know how a clang driver change that only affects SYCL and OpenMP
offloading could cause JIT to fail.
https://github.com/llvm/llvm-project/pull/132037
___
cfe-commits
@@ -1076,13 +1076,11 @@ Language and Target-Independent Features
Freestanding Builds
---
Passing the ``-ffreestanding`` flag causes Clang to build for a freestanding
-(rather than a hosted) environment. The ``__STDC_HOSTED__`` predefined macro
-will expand to ``
https://github.com/jhuber6 approved this pull request.
Seems reasonable so long as we know that `SPIR-V` is always a GPU. I'll defer
to SPIR people.
https://github.com/llvm/llvm-project/pull/126956
___
cfe-commits mailing list
cfe-commits@lists.llvm.o
@@ -1073,6 +1073,29 @@ inputs. Here is some example of ``$``-prefixed options:
Language and Target-Independent Features
+Freestanding Builds
+---
+Passing the ``-ffreestanding`` flag causes Clang to build for a freestand
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/131884
___
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/132495
___
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/129347
___
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/132868
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1073,6 +1073,29 @@ inputs. Here is some example of ``$``-prefixed options:
Language and Target-Independent Features
+Freestanding Builds
+---
+Passing the ``-ffreestanding`` flag causes Clang to build for a freestand
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/132737
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -9337,6 +9337,11 @@ void LinkerWrapper::ConstructJob(Compilation &C, const
JobAction &JA,
CmdArgs.push_back(
Args.MakeArgString("--device-linker=" + TC.getTripleString() + "="
+
"-lclang_rt.builtins"));
+ bool HasFlan
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/132737
>From abf867e63c939e70916017e3abcabc5a947fb41e Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Mar 2025 09:01:08 -0500
Subject: [PATCH 1/2] [Flang] Link `-lflang_rt.runtime` if available on the
device
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/132737
Summary:
Now that we can build the Fortran runtime on the GPU (mostly) we should
be able to implicitly link it if it exists. This matches the normal
behavior where it is included implicity. No tests because it
wo
@@ -0,0 +1,32 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 5
jhuber6 wrote:
Move to normal `CodeGen`.
https://github.com/llvm/llvm-project/pull/129347
___
cfe-c
https://github.com/jhuber6 commented:
I'll defer to @arsenm for the final verdict.
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
https://github.com/jhuber6 commented:
So this is just an IR lowering? We'd probably need some more conclusive tests
that it works as expected for exceptional values, but I'm going to guess it was
copied from an existing implementation so we could just refer to that one.
https://github.com/llvm
@@ -332,6 +332,8 @@ Target Specific Changes
AMDGPU Support
^^
+- Bump the default code object version to 6. ROCm 6.3 is required to run any
program compiled with COV6.
jhuber6 wrote:
Is it really? What runtime changes actually were required. Figu
https://github.com/jhuber6 approved this pull request.
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
https://github.com/jhuber6 approved this pull request.
I wonder if we should just make all of these `isAMDGPU()` as well.
https://github.com/llvm/llvm-project/pull/131379
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/131332
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
@sarnex I'm assuming you're somewhat familiar with SPIR-V and the backend. We
really need a way to call SPIR-V builtins directly, i.e. some way to get clang
to lower something like `__builtin_spirv_ballot()` to
`OpGroupNonUniformBallot`. I don't know how much SPIR-V exposes for
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/131884
Summary:
The `--offload-arch` option is very complicated, but roughly behaves as
the `-march` option for several compilations at once. This creates
problems when we try to compbine multiple separate architectures
https://github.com/jhuber6 commented:
If all this does is call the `amdgpu` builtins, is it possible to just include
that one? I think the only thing that differs is the address spaces so we could
probably just undef those.
https://github.com/llvm/llvm-project/pull/131164
_
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/131884
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -332,6 +332,8 @@ Target Specific Changes
AMDGPU Support
^^
+- Bump the default code object version to 6. ROCm 6.3 is required to run any
program compiled with COV6.
jhuber6 wrote:
Yes, I have no clue why we don't provide that in the HSA header
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/132037
Summary:
Offloading tends to have a bound architecture that directly correponds
to the `-mcpu` argument for that embedded job. This is currently handled
by the GPU offloading toolchains, but is ignored by the CPU
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/134230
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> How'd you manage to find the right ones? IMO we should be using
> include-what-you-use on these to make sure we get it right (if you have
> already, disregard this).
>
> Also, can you share before-split/after-split/after-this build time
> benchmarks? Does this get us back to
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/132870
>From 3fe8e18a4fb725b345210f5dffa13716cc7fb7f0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Mar 2025 22:36:04 -0500
Subject: [PATCH] [Clang][AMDGPU] Remove special handling for COV4 libraries
Summa
@@ -0,0 +1,32 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 5
+// RUN: %clang --cuda-device-only -nogpuinc -nogpulib -emit-llvm -S -o - %s |
FileCheck %s
jhuber6 wrote:
I feel like this test doesn't need t
jhuber6 wrote:
I'd say you can merge it once CI is green.
https://github.com/llvm/llvm-project/pull/132252
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1273,13 +1273,11 @@ COMPILER_RT_VISIBILITY int
__llvm_profile_set_file_object(FILE *File,
return 0;
}
-int __llvm_write_custom_profile(const char *Target,
-const __llvm_profile_data *DataBegin,
-const __llv
@@ -1073,6 +1073,28 @@ inputs. Here is some example of ``$``-prefixed options:
Language and Target-Independent Features
+Freestanding Builds
+---
+Passing the ``-ffreestanding`` flag causes Clang to build for a freestand
https://github.com/jhuber6 commented:
It worked before your patch right? Is this what it exposed before then?
https://github.com/llvm/llvm-project/pull/132966
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailma
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/132870
>From 93fc26d67f0f0dc94fef853a129753d3a991ef6e Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Mar 2025 22:36:04 -0500
Subject: [PATCH] [Clang][AMDGPU] Remove special handling for COV4 libraries
Summa
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/132870
>From 09c8fbf137fc975029fa9dee89af0d52ac2876b5 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Mar 2025 22:36:04 -0500
Subject: [PATCH] [Clang][AMDGPU] Remove special handling for COV4 libraries
Summa
@@ -33,14 +33,8 @@ function(add_startup_object name)
set_target_properties(${fq_target_name}.exe PROPERTIES
RUNTIME_OUTPUT_DIRECTORY ${LIBC_LIBRARY_DIR}
RUNTIME_OUTPUT_NAME ${name}.o)
-# FIXME: A bug in the AMDGPU LTO pass is incorrectly removing the kernels
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/133164
>From 8c8885d486ac72145d7fd7ba003db7ea9ab17a1f Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 26 Mar 2025 16:03:20 -0500
Subject: [PATCH 1/2] [Clang] Make `--lto-partitions` only default for HIP
Summary
jhuber6 wrote:
This seems to have broken LTO linking / introduced some non-determinism. I
noticed that the LLVM libc `crt1.o` file was missing a lot of definitions for
some reason and traces it back to this. Here's the IR that comes out of `clang`
https://godbolt.org/z/4fz35PaPb.
If we take t
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/133164
Summary:
The default behavior for LTO on other targets does not specify the
number of LTO partitions. Recent changes made this default to 8 on
AMDGPU which had some issues with the `libc` project. The option to
d
@@ -708,6 +712,34 @@ void amdgpu::getAMDGPUTargetFeatures(const Driver &D,
options::OPT_m_amdgpu_Features_Group);
}
+static unsigned GetFullLTOPartitions(const Driver &D, const ArgList &Args) {
+ const Arg *A = Args.getLastArg(options::OPT_flto_par
jhuber6 wrote:
Thinking on this, might just be a very poor interaction between
`-lto-partitions` and `-lto-emit-llvm`. Since it splits it up.
https://github.com/llvm/llvm-project/pull/128509
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
jhuber6 wrote:
I'll clean up the option later as well. `--flto` with double dashes is wrong.
https://github.com/llvm/llvm-project/pull/133164
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co
@@ -708,6 +711,33 @@ void amdgpu::getAMDGPUTargetFeatures(const Driver &D,
options::OPT_m_amdgpu_Features_Group);
}
+static unsigned getFullLTOPartitions(const Driver &D, const ArgList &Args) {
+ const Arg *A = Args.getLastArg(options::OPT_flto_par
jhuber6 wrote:
Reverting this patch locally also fixes one of the `libc` tests that was
failing, so I'm going to assume they're related.
https://github.com/llvm/llvm-project/pull/128509
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://l
jhuber6 wrote:
I'm thinking this should be default only for HIP (maybe OpenMP later) because
the option is HIP only and it confounds attempts to override it by inserting a
linker option otherwise.
https://github.com/llvm/llvm-project/pull/128509
___
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/133164
>From 8c8885d486ac72145d7fd7ba003db7ea9ab17a1f Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 26 Mar 2025 16:03:20 -0500
Subject: [PATCH 1/3] [Clang] Make `--lto-partitions` only default for HIP
Summary
@@ -1393,6 +1393,8 @@ def fhip_emit_relocatable : Flag<["-"],
"fhip-emit-relocatable">,
HelpText<"Compile HIP source to relocatable">;
def fno_hip_emit_relocatable : Flag<["-"], "fno-hip-emit-relocatable">,
HelpText<"Do not override toolchain to compile HIP source to reloc
@@ -1273,6 +1273,7 @@ COMPILER_RT_VISIBILITY int
__llvm_profile_set_file_object(FILE *File,
return 0;
}
+#ifdef COMPILER_RT_GPU_ENTRYPOINT
jhuber6 wrote:
Can't we just use `__APPLE__`?
https://github.com/llvm/llvm-project/pull/132966
_
https://github.com/jhuber6 approved this pull request.
Seems in line with the weird workarounds we already use.
https://github.com/llvm/llvm-project/pull/133024
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
2301 - 2400 of 2694 matches
Mail list logo
