https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/114843
Summary:
Previously we extracted archives and did special symbol resolution on
them, this was mostly done because the nvlink executable couldn't handle
archives natively. Since I have added a wrapper around it th
@@ -7,9 +7,9 @@
; RUN: opt -O3 -S < %s | FileCheck -check-prefix=OPT %s
; RUN: opt -mtriple=amdgcn-- -O3 -S < %s | FileCheck -check-prefix=OPT %s
-; RUN: opt -mtriple=amdgcn-- -O3 -mattr=+wavefrontsize32 -S < %s | FileCheck
-check-prefix=OPT %s
-; RUN: opt -mtriple=amdgcn-- -
@@ -7,9 +7,9 @@
; RUN: opt -O3 -S < %s | FileCheck -check-prefix=OPT %s
; RUN: opt -mtriple=amdgcn-- -O3 -S < %s | FileCheck -check-prefix=OPT %s
-; RUN: opt -mtriple=amdgcn-- -O3 -mattr=+wavefrontsize32 -S < %s | FileCheck
-check-prefix=OPT %s
-; RUN: opt -mtriple=amdgcn-- -
@@ -1024,6 +1024,15 @@ GCNTTIImpl::instCombineIntrinsic(InstCombiner &IC,
IntrinsicInst &II) const {
}
break;
}
+ case Intrinsic::amdgcn_wavefrontsize: {
+// TODO: this is a workaround for the pseudo-generic target one gets with
no
+// specified mcpu, which
jhuber6 wrote:
Ping
https://github.com/llvm/llvm-project/pull/110179
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,154 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
@@ -0,0 +1,154 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
@@ -0,0 +1,154 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
@@ -0,0 +1,154 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
@@ -0,0 +1,86 @@
+//===-- gpuintrin.h - Generic GPU intrinsic functions
-===//
+//
+// 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: Apa
@@ -0,0 +1,86 @@
+//===-- gpuintrin.h - Generic GPU intrinsic functions
-===//
+//
+// 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: Apa
@@ -0,0 +1,154 @@
+//===-- nvptxintrin.h - NVPTX intrinsic functions
-===//
+//
+// 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
@@ -0,0 +1,155 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
@@ -0,0 +1,155 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
@@ -0,0 +1,155 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
@@ -0,0 +1,155 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
@@ -0,0 +1,155 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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
@@ -0,0 +1,119 @@
+//===-- gpuintrin.h - Generic GPU intrinsic functions
-===//
+//
+// 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
@@ -0,0 +1,155 @@
+//===-- amdgpuintrin.h - AMDPGU intrinsic functions
---===//
+//
+// 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 created
https://github.com/llvm/llvm-project/pull/114298
Summary:
These flags were used in the very early days while we were trying to
port stuff. Now that we just pass bitcode to the device link job it
can be easily replaced by `-Xoffload-linker foo.bc`.
>From 1a38b
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/114298
>From 2d8e6cba481617f2158d6ac687210636747ea168 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 30 Oct 2024 15:05:39 -0500
Subject: [PATCH] [LinkerWrapper] Remove handling of special bitcode flags
Summary
jhuber6 wrote:
> I'd prefer we have SYCL linking run through LLD rather than the
> linker-wrapper tool approach, but I don't feel strongly enough to block this.
I see this as a temporary hack around not having a proper SPIR-V linker /
backend in LLVM yet. It's less of a linker-wrapper tool and
https://github.com/jhuber6 commented:
A default constructed vector should just be empty, I don't think it would cause
the issue the sanitizer is seeing.
https://github.com/llvm/llvm-project/pull/114434
___
cfe-commits mailing list
cfe-commits@lists.ll
jhuber6 wrote:
> Just out of curiosity: Are all these things documented reasonably well
> somewhere?
It's in the clang reference, but probably could be part of a better tutorial or
something.
https://github.com/llvm/llvm-project/pull/114401
___
cfe-
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/114488
___
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/114298
___
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 guess this is good for now, but we really need to work with how to actually
handle multiple toolchains at once.
https://github.com/llvm/llvm-project/pull/113509
___
cfe-commits mailing list
cfe-
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/113613
___
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/112025
___
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/111890
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -264,12 +264,14 @@ void HIPAMDToolChain::addClangTargetOptions(
CC1Args.push_back("-fapply-global-visibility-to-externs");
}
- // For SPIR-V we embed the command-line into the generated binary, in order
to
- // retrieve it at JIT time and be able to do target speci
jhuber6 wrote:
> We don't use `offload` at the moment, that's for HIPSPV. Of course, future,
> fancy work is more than welcome, but this merely slots into the existing
> infra and current use cases.
I'm not a huge fan of smuggling what is essentially a Toolchain behind what was
intended as a
https://github.com/jhuber6 commented:
So, I'm thinking that SPIR-V here fits better as a triple. I've been wanting to
generalize the `--offload` option to behave more like `-fopenmp-targets`. I.e.
we would have `--offload=spirv64-amd-amdhsa,amdgcn-amd-amdhsa
-Xarch_device_amdgcn-amd-amdhsa --o
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/110179
>From c9431203b10c930587a07eed099df9e3e4ebae00 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 26 Sep 2024 16:47:14 -0500
Subject: [PATCH 1/6] [Clang] Implement resource directory headers for common
GPU
jhuber6 wrote:
Ping now that https://github.com/llvm/llvm-project/pull/111890 landed and the
CI is green.
https://github.com/llvm/llvm-project/pull/111921
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/l
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/113715
>From 8042f288085188695b220460551b71a503e6cfa1 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 25 Oct 2024 12:23:15 -0500
Subject: [PATCH] [LinkerWrapper] Remove in-house handling of LTO
Summary:
This sh
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/111890
___
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/112025
___
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/111921
>From 098e554223f843193ee142ea5f9b0a556477d309 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 10 Oct 2024 18:26:27 -0500
Subject: [PATCH] [LinkerWrapper] Extract device archives if symbol is used on
the
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/113934
Summary:
This flag is pretty canonical in ELF linkers, it allows us to force the
link job to extract a library if it defines a specific symbol. This is
mostly useful for letting us forcibly extract things that do
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/84420
>From 8d63e56aa5af8b86d757d1f1ff68267d3dd1ccd4 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 7 Mar 2024 15:48:00 -0600
Subject: [PATCH] [Offload] Move HIP and CUDA to new driver by default
Summary:
This
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/115777
Summary:
GPU targets support several different address spaces which have
differing semantics. When targeting C/C++ we have a very pessimistic
view that these address spaces are completely incompatible. This has a
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/115777
>From 34eb41f58518c79c627b5c1cc522c4e142c2d420 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 11 Nov 2024 16:10:31 -0600
Subject: [PATCH] [Clang] Add `-fdefault-generic-addrspace` flag for targeting
GPU
@@ -1579,7 +1579,7 @@ NamedDecl *Sema::getCurFunctionOrMethodDecl() const {
}
LangAS Sema::getDefaultCXXMethodAddrSpace() const {
- if (getLangOpts().OpenCL)
+ if (getLangOpts().OpenCL || getLangOpts().OpenCLGenericAddressSpace)
jhuber6 wrote:
I think it's
jhuber6 wrote:
https://godbolt.org/z/qWGaejTx9 for this case, I'm wondering if there's a way
to resolve this by considering the AS as part of the pointer, since I don't
know if AS means anything on a non-pointer type.
https://github.com/llvm/llvm-project/pull/115777
___
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/115545
>From 9b8cb87e0e12899df3a5af7f312f637a6c242921 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 8 Nov 2024 15:42:04 -0600
Subject: [PATCH 1/4] [Clang] Add support for scoped atomic thread fence
Summary:
P
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/115545
>From 9b8cb87e0e12899df3a5af7f312f637a6c242921 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 8 Nov 2024 15:42:04 -0600
Subject: [PATCH 1/4] [Clang] Add support for scoped atomic thread fence
Summary:
P
@@ -5133,6 +5133,132 @@ RValue CodeGenFunction::EmitBuiltinExpr(const
GlobalDecl GD, unsigned BuiltinID,
Builder.SetInsertPoint(ContBB);
return RValue::get(nullptr);
}
+ case Builtin::BI__scoped_atomic_thread_fence: {
+auto ScopeModel = AtomicScopeModel::create(
jhuber6 wrote:
> > This has a lot of unfortable effects that limit using address spaces in C++
> > as well
> > as making it more difficult to work with.
>
> Can you give some examples?
>
> It sounds that what you really want is for address space qualifiers to not be
> part of a type signature
jhuber6 wrote:
> > > This has a lot of unfortable effects that limit using address spaces in
> > > C++ as well
> > > as making it more difficult to work with.
> >
> >
> > Can you give some examples?
> > It sounds that what you really want is for address space qualifiers to not
> > be part of
jhuber6 wrote:
> I think I generally agree with @AlexVlx argument. While the patch may solve
> you immediate issue, I think it's not going to give you a usable compilation
> model for AS-qualified pointers.
>
> If you are defining your own C++ extension along the lines of
> CUDA/HIP/OpenCL, y
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/115545
>From d8105f5626318868ada0deba0b5755999a47abb2 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 8 Nov 2024 15:42:04 -0600
Subject: [PATCH 1/2] [Clang] Add support for scoped atomic thread fence
Summary:
P
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/115545
Summary:
Previously we added support for all of the atomic GNU extensions with
optional memory scoped except for `__atomic_thread_fence`. This patch
adds support for that. This should ideally allow us to generica
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/115545
>From d8105f5626318868ada0deba0b5755999a47abb2 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 8 Nov 2024 15:42:04 -0600
Subject: [PATCH] [Clang] Add support for scoped atomic thread fence
Summary:
Previ
@@ -0,0 +1,179 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 5
+// RUN: %clang_cc1 %s -emit-llvm -o - -triple=amdgcn-amd-amdhsa -ffreestanding
\
+// RUN: -fvisibility=hidden | FileCheck --check-prefix=AMDGCN %s
+//: %clan
@@ -5133,6 +5133,135 @@ RValue CodeGenFunction::EmitBuiltinExpr(const
GlobalDecl GD, unsigned BuiltinID,
Builder.SetInsertPoint(ContBB);
return RValue::get(nullptr);
}
+ case Builtin::BI__scoped_atomic_thread_fence: {
+auto ScopeModel = AtomicScopeModel::create(
@@ -0,0 +1,179 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
UTC_ARGS: --version 5
+// RUN: %clang_cc1 %s -emit-llvm -o - -triple=amdgcn-amd-amdhsa -ffreestanding
\
+// RUN: -fvisibility=hidden | FileCheck --check-prefix=AMDGCN %s
+//: %clan
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/115507
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Joseph Huber
Date: 2024-11-11T12:38:27-06:00
New Revision: da78ac5d331953d3386fd56cd7979022be7400cf
URL:
https://github.com/llvm/llvm-project/commit/da78ac5d331953d3386fd56cd7979022be7400cf
DIFF:
https://github.com/llvm/llvm-project/commit/da78ac5d331953d3386fd56cd7979022be7400cf.diff
jhuber6 wrote:
Seems there's something *slightly* different from the autogenerated IR for the
language test. I'll see if I can fix it.
https://github.com/llvm/llvm-project/pull/110179
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lis
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/110179
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -370,6 +370,8 @@ Error runLinker(ArrayRef Files, const ArgList
&Args) {
// Render the linker arguments and add the newly created image. We add it
// after the output file to ensure it is linked with the correct libraries.
StringRef LinkerPath = Args.getLastArgValue(OP
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/116077
Summary:
This was done a long time ago for OpenMP, but it seems HIP was never
updated. This patch rectifies that. The default for the LLVM backend is
5 so this is probably required for some stuff.
>From bed638b
jhuber6 wrote:
> Hmm, I thought this is already the default one if nothing is specified
My thoughts as well, but apparently not. Something else no one ever upstreamed
from the AMD fork.
https://github.com/llvm/llvm-project/pull/116077
___
cfe-commits
jhuber6 wrote:
> Which is the gist of what I am saying: linguistic constructs carry semantics
> (meaning), we should not work back from their disembodied lowering into a
> target specific quantity to generalise the latter into a linguistic construct
> beyond the initial one. CUDA made language
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/115777
>From 6de44ccb26b545fe29101bf1b7b23b5c2eef2a8f Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 11 Nov 2024 16:10:31 -0600
Subject: [PATCH 1/4] [Clang] Add `-fdefault-generic-addrspace` flag for
targeting
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/116077
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> > For AMDGPU and NVPTX, pointers are allowed to drop their address spaces
> > transparently. So, `void AS(3) *` can convert to `void *`. Languages like
> > CUDA and SYCL and HIP use these 'language' address spaces to describe
> > exactly this, but my assertion is that it's mor
jhuber6 wrote:
> > Interesting, though reading through that I didn't see any mentions of
> > implicit casts. It's simply stating that they can do casting if the target
> > lists them as a subset.
>
> That matches my understanding -- implicit or explicit casts require a subset
> relationship,
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/115545
>From be73e1600846f6026c03d2e3107b4237f54c51ac Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 8 Nov 2024 15:42:04 -0600
Subject: [PATCH 1/5] [Clang] Add support for scoped atomic thread fence
Summary:
P
@@ -3060,6 +3060,9 @@ Generic_GCC::Generic_GCC(const Driver &D, const
llvm::Triple &Triple,
: ToolChain(D, Triple, Args), GCCInstallation(D),
CudaInstallation(D, Triple, Args), RocmInstallation(D, Triple, Args) {
getProgramPaths().push_back(getDriver().Dir);
+ llv
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/112245
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Joseph Huber
Date: 2024-10-31T10:59:56-05:00
New Revision: 0d499f9043fed14ff8c7f9e24e19206c93aee5dd
URL:
https://github.com/llvm/llvm-project/commit/0d499f9043fed14ff8c7f9e24e19206c93aee5dd
DIFF:
https://github.com/llvm/llvm-project/commit/0d499f9043fed14ff8c7f9e24e19206c93aee5dd.diff
jhuber6 wrote:
Should be fixed in
https://github.com/llvm/llvm-project/commit/0d499f9043fed14ff8c7f9e24e19206c93aee5dd
https://github.com/llvm/llvm-project/pull/112245
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-
jhuber6 wrote:
Can this be done through `-Xoffload-linker`?
https://github.com/llvm/llvm-project/pull/114401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> Faux "generic" IR sounds like a problematic concept, do you have an example?
It's what `libc` and the ROCm DeviceLibs do, compile without `-mcpu` and don't
use any target specific attributes or intrinsics, then link it into a TU later
when the target is known. It's find in pri
jhuber6 wrote:
> As per my other reply, this is not an invalid use case, but somewhat niche.
> We can have a control value for disabling this early fold, for such builds,
> to avoid the need to do two builds (which might also be fine for `libc`). I
> don't think ROCDL uses the intrinsic at all
jhuber6 wrote:
> For the purposes of experimentation, `-Xoffload-linker` is sufficient that
> this change is not necessary.
Also worth noting that `-Xoffload-linker-amdgcn-amd-amdhsa` should work if you
just want to target a single toolchain.
https://github.com/llvm/llvm-project/pull/114401
_
jhuber6 wrote:
> > Can this be done through `-Xoffload-linker`?
>
> No. I tried several different things, but was not able to get the right
> command line option passed to lld (in the
> clang->clang-linker-wrapper->clang->lld chain).
This works for me,
```console
$ clang input.c -fopenmp --of
jhuber6 wrote:
> The toothpaste is out of the tube once the IR is produced. If some toolchain
> were relying on the global target machine features, there are opportunities
> for error on each tool invocation. The absence of the attribute does not tell
> you what the final compilation context w
https://github.com/jhuber6 approved this pull request.
Good catch, thanks.
https://github.com/llvm/llvm-project/pull/114488
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
I think the current use of this intrinsic in 'generic' IR is sound so long as
it's not guarding anything ABI related. Right now it's just used for loop
bounds and array offsets pretty much. Though long-term I agree that it's
probably most sound to just put these as separate bui
jhuber6 wrote:
> Just adding this to the pass pipeline where it is is no better than just
> doing it in instcombine, which is the natural place to do this. This patch,
> like instcombine, still has the problem that we don't know if we're producing
> the final code.
Yeah that was my concern, i
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/115499
___
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/115545
>From d8105f5626318868ada0deba0b5755999a47abb2 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 8 Nov 2024 15:42:04 -0600
Subject: [PATCH 1/3] [Clang] Add support for scoped atomic thread fence
Summary:
P
jhuber6 wrote:
> > I agree in general that C/C++ has no semantic meaning ascribed to address
> > spaces.
>
> Err, C does. Please see TR 18037
> (https://standards.iso.org/ittf/PubliclyAvailableStandards/c051126_ISO_IEC_TR_18037_2008.zip)
>
> AIUI, we've extended the C extension into C++, so w
jhuber6 wrote:
> I'm not sure about this. What does `compiler-rt` provide?
It's `clang_rt.builtins`. So, basically complex number multiplication /
division, wide integer stuff (I think the backend handles i128 now though). We
currently have a wrapper header that defined `__mulsc3` for the devi
jhuber6 wrote:
> I like this direction and I think it should be the right way. However, IMHO,
> I think it needs discussion (and potentially an RFC).
Moving from the header to the definition in `compiler-rt` would warrant an RFC,
this patch just automatically links something that exists and wi
https://github.com/jhuber6 reopened
https://github.com/llvm/llvm-project/pull/102096
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
If we already have per-function metadata, I'm wondering how difficult it would
be to put this handling in the linker. AFAIK there's already handling for
`call-graph-profile` which can inform the linker of the call-graph, so we could
potentially just walk that graph, find the dia
Author: Joseph Huber
Date: 2024-09-22T08:16:01-05:00
New Revision: 5b9206dbe42a149f44cc267508d439717912cb1d
URL:
https://github.com/llvm/llvm-project/commit/5b9206dbe42a149f44cc267508d439717912cb1d
DIFF:
https://github.com/llvm/llvm-project/commit/5b9206dbe42a149f44cc267508d439717912cb1d.diff
Author: Joseph Huber
Date: 2024-09-22T08:04:20-05:00
New Revision: 68e2b695eae06b42261ecdc145c1f1ece57cd14c
URL:
https://github.com/llvm/llvm-project/commit/68e2b695eae06b42261ecdc145c1f1ece57cd14c
DIFF:
https://github.com/llvm/llvm-project/commit/68e2b695eae06b42261ecdc145c1f1ece57cd14c.diff
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/102096
___
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/109152
___
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/110139
Summary:
We need all inputs to `nvlink` to end in `.cubin` while the rest of the
compiler toolchain wants `.o`. Previously we copied `.o` file to
`.cubin` files, but this is wasteful. Instead, we can just create
@@ -1,9 +1,10 @@
-! RUN %flang -### --target=x86_64-unknown-linux-gnu -fopenmp
--offload-arch=gfx90a -Xoffload-linker a %s 2>&1 | FileCheck %s
--check-prefixes=CHECK-XLINKER
+! Test the -Xoffload-linker flag that forwards link commands to the
clang-linker-wrapper used
+! to hel
jhuber6 wrote:
> @rnk Are symlinks OK to use on windows?
There's a caveat in the implementation stating that the links are soft on Linux
but hard on Windows (as soft links require super-user privileges). I'm pretty
sure a hard link also does the job here? Since all we need to do is give the
s
jhuber6 wrote:
Build bot says no, apparently. "The system cannot move the file to a different
disk drive."
https://github.com/llvm/llvm-project/pull/110139
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/
@@ -1,9 +1,10 @@
-! RUN %flang -### --target=x86_64-unknown-linux-gnu -fopenmp
--offload-arch=gfx90a -Xoffload-linker a %s 2>&1 | FileCheck %s
--check-prefixes=CHECK-XLINKER
+! Test the -Xoffload-linker flag that forwards link commands to the
clang-linker-wrapper used
+! to hel
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/110139
>From 393e05145d0c31a3b1b254f97a357c776617898c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 26 Sep 2024 11:04:46 -0500
Subject: [PATCH 1/2] [nvlink-wrapper] Use a symbolic link instead of copying
the
1701 - 1800 of 2686 matches
Mail list logo
