jhuber6 wrote:
> New intrinsic sounds right - a constant frequency counter is a different
> thing to a variable frequency counter.
>
> "Steady" implies unchanging, so I'd agree with `readfixedfreqtimer` or
> similar.
I think `steady` has sufficient context here, (i.e.
Author: Joseph Huber
Date: 2024-02-12T08:15:48-06:00
New Revision: f5fd0deb2371d0bae3bef2563f50e005a140fc6d
URL:
https://github.com/llvm/llvm-project/commit/f5fd0deb2371d0bae3bef2563f50e005a140fc6d
DIFF:
https://github.com/llvm/llvm-project/commit/f5fd0deb2371d0bae3bef2563f50e005a140fc6d.diff
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81331
>From 30341079e795c2668588b791f2c97b44006e7a04 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 9 Feb 2024 16:13:42 -0600
Subject: [PATCH] [WIP][LLVM] Add `__builtin_readsteadycounter` intrinsic and
jhuber6 wrote:
> Are we assuming any particular relationship to __builtin_readcyclecounter in
> terms of scales etc?
>
> __builtin_readsteadycounter could be used to access x86 MPERF clock counters,
> but to access the corresponding APERF clock we'd then need a
>
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81331
>From 30341079e795c2668588b791f2c97b44006e7a04 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 9 Feb 2024 16:13:42 -0600
Subject: [PATCH] [WIP][LLVM] Add `__builtin_readsteadycounter` intrinsic and
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81331
>From 109939223e7944472363134d72a223524e1e3f0a Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 9 Feb 2024 16:13:42 -0600
Subject: [PATCH] [WIP][LLVM] Add `__builtin_readsteadycounter` intrinsic and
jhuber6 wrote:
Added clang test and renamed to `readsteadycounter` as I think it's more
descriptive and matches the existing `readcyclecounter` better.
https://github.com/llvm/llvm-project/pull/81331
___
cfe-commits mailing list
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/81331
___
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/81331
>From 164d9775046d273fa45e9934cea1db07fdd2ca79 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 9 Feb 2024 16:13:42 -0600
Subject: [PATCH] [WIP][LLVM] Add `__builtin_readsteadycounter` intrinsic and
@@ -312,6 +312,12 @@ void IntrinsicLowering::LowerIntrinsicCall(CallInst *CI) {
CI->replaceAllUsesWith(ConstantInt::get(Type::getInt64Ty(Context), 0));
break;
}
+ case Intrinsic::readfixedtimer: {
+errs() << "WARNING: this target does not support the
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/81331
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> Generally looks good to me. Just not sure about the name. "fixed timer"
> sounds pretty confusing to me. probably `readfixedfreqtimer`?
Naming is the hard part. I was also thinking about `readrealtimecounter` or
something. Maybe `readsteadycounter`?
@@ -312,6 +312,12 @@ void IntrinsicLowering::LowerIntrinsicCall(CallInst *CI) {
CI->replaceAllUsesWith(ConstantInt::get(Type::getInt64Ty(Context), 0));
break;
}
+ case Intrinsic::readfixedtimer: {
+errs() << "WARNING: this target does not support the
jhuber6 wrote:
Formatting is expected to fail to preserve local style.
https://github.com/llvm/llvm-project/pull/81331
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 ready_for_review
https://github.com/llvm/llvm-project/pull/81331
___
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/81331
___
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/81331
___
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/81331
>From 6b85d8edfe35d3952fc4e67e249175d9f8f734c6 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 9 Feb 2024 16:13:42 -0600
Subject: [PATCH] [WIP][LLVM] Add `__builtin_readfixedtimer` intrinsic and
buiiltin
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/81331
___
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/81331
>From 4008cb94b59ea1be8aa6936c4dc6b5b7ad4e749a Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 9 Feb 2024 16:13:42 -0600
Subject: [PATCH] [WIP][LLVM] Add `__builtin_readfixedtimer` intrinsic and
buiiltin
jhuber6 wrote:
This is a draft, I'm trying to get this to map to either `s_memtime` or
`s_sendmsg_rtn(0x83)` depending on the target for AMDGPU. Currently, it will
recognize the new intrinsic but just lower it to `i64 0`. I'm not overly
familiar with the backend, so any suggestions would be
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/81331
Summary:
This patch adds a new intrinsic and builtin function mirroring the
existing `__builtin_readcyclecounter`. The difference is that this
implementation targets a separate counter that some targets have
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/81277
___
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/81277
>From 5c9bc83db318d5c8608108942e494d6f0c1a27d5 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 9 Feb 2024 10:50:20 -0600
Subject: [PATCH] [NVPTX] Add clang builtin for `__nvvm_reflect` intrinsic
Summary:
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/81033
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -140,6 +140,17 @@ define void @test_exit() {
ret void
}
+; CHECK-LABEL: test_globaltimer
+define i64 @test_globaltimer() {
+; CHECK: mov.u64 %r{{.*}}, %globaltimer;
+ %a = tail call i64 @llvm.nvvm.read.ptx.sreg.globaltimer()
jhuber6 wrote:
Done
@@ -140,6 +140,17 @@ define void @test_exit() {
ret void
}
+; CHECK-LABEL: test_globaltimer
+define i64 @test_globaltimer() {
+; CHECK: mov.u64 %r{{.*}}, %globaltimer;
+ %a = tail call i64 @llvm.nvvm.read.ptx.sreg.globaltimer()
jhuber6 wrote:
@@ -1624,8 +1624,9 @@ def int_nvvm_compiler_error :
def int_nvvm_compiler_warn :
Intrinsic<[], [llvm_anyptr_ty], [], "llvm.nvvm.compiler.warn">;
-def int_nvvm_reflect :
- Intrinsic<[llvm_i32_ty], [llvm_anyptr_ty], [IntrNoMem], "llvm.nvvm.reflect">;
+def int_nvvm_reflect
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81277
>From 7b97388a5f251684cf4ae69c3b0cae0ff6fe1397 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 9 Feb 2024 10:50:20 -0600
Subject: [PATCH 1/2] [NVPTX] Add clang builtin for `__nvvm_reflect` intrinsic
@@ -1624,8 +1624,9 @@ def int_nvvm_compiler_error :
def int_nvvm_compiler_warn :
Intrinsic<[], [llvm_anyptr_ty], [], "llvm.nvvm.compiler.warn">;
-def int_nvvm_reflect :
- Intrinsic<[llvm_i32_ty], [llvm_anyptr_ty], [IntrNoMem], "llvm.nvvm.reflect">;
+def int_nvvm_reflect
@@ -1624,8 +1624,9 @@ def int_nvvm_compiler_error :
def int_nvvm_compiler_warn :
Intrinsic<[], [llvm_anyptr_ty], [], "llvm.nvvm.compiler.warn">;
-def int_nvvm_reflect :
- Intrinsic<[llvm_i32_ty], [llvm_anyptr_ty], [IntrNoMem], "llvm.nvvm.reflect">;
+def int_nvvm_reflect
@@ -159,6 +159,7 @@ BUILTIN(__nvvm_read_ptx_sreg_pm3, "i", "n")
BUILTIN(__nvvm_prmt, "UiUiUiUi", "")
BUILTIN(__nvvm_exit, "v", "r")
+BUILTIN(__nvvm_reflect, "UicC*", "r")
jhuber6 wrote:
It's in the `NVPTXUsage.rst`, and
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/81277
___
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/81277
Summary:
Some recent support made usage of `__nvvm_reflect` more consistent. We
should expose it as an intrinsic rather than forcing users to externally
define the function.
>From
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/81193
___
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/81193
Summary:
Currently, the linker wrapper sourts input files into different link
jobs according to their architectures. Here we assume each architecture
is a unique and incompatible link job unless they are
@@ -0,0 +1,698 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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:
@@ -0,0 +1,698 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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:
@@ -0,0 +1,698 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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:
@@ -0,0 +1,698 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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:
@@ -0,0 +1,698 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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:
@@ -0,0 +1,698 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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:
@@ -0,0 +1,698 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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:
@@ -0,0 +1,698 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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:
https://github.com/jhuber6 commented:
Some more comments
https://github.com/llvm/llvm-project/pull/81058
___
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/81058
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,716 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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:
@@ -0,0 +1,716 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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:
@@ -0,0 +1,716 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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:
@@ -0,0 +1,716 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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:
@@ -0,0 +1,716 @@
+//===-- ExpandVariadicsPass.cpp *- C++ -*-=//
+//
+// 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:
https://github.com/jhuber6 commented:
Thanks for working on this. A few quick nits, overall looks like lots of
straightforward testing with a beefy new pass.
https://github.com/llvm/llvm-project/pull/81058
___
cfe-commits mailing list
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/81058
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
Okay, `__nvvm_reflect` doesn't work fully here because the `nanosleep` builtin
I added requires `sm_70` at the clang level. Either means I'd need to go back
to inline assembly or remove that requirement at least from clang so it's a
backend failure.
jhuber6 wrote:
> > This patch, which simply makes it legal on all architectures but do nothing
> > is it's older than sm_70.
>
> I do not think this is the right thing to do. "do nothing" is not what one
> would expect from a `nanosleep`.
Thanks, I made this a draft because I figured it
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/81033
Summary;
The LLVM C library currently uses `nanosleep` in the RPC interface and
for the C library `nanosleep` function. We build the LLVM C library for
every single NVPTX architecture individually currently,
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/81015
___
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/81015
>From ed6b669d7d427f2cb4d87f9d4a8063e1b919fc03 Mon Sep 17 00:00:00 2001
From: Sh0g0-1758
Date: Wed, 7 Feb 2024 21:11:58 +0530
Subject: [PATCH 1/5] Add a Null Check
---
clang/lib/Sema/SemaOpenMP.cpp | 2 ++
1
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81015
>From c8ada809964eac64f6cb0c103593748b86932163 Mon Sep 17 00:00:00 2001
From: Sh0g0-1758
Date: Wed, 7 Feb 2024 21:11:58 +0530
Subject: [PATCH 1/5] Add a Null Check
---
clang/lib/Sema/SemaOpenMP.cpp | 2 ++
1
Author: Joseph Huber
Date: 2024-02-07T13:03:31-06:00
New Revision: 347ab99a5c6d096beb7378794c6255dca2a866e6
URL:
https://github.com/llvm/llvm-project/commit/347ab99a5c6d096beb7378794c6255dca2a866e6
DIFF:
https://github.com/llvm/llvm-project/commit/347ab99a5c6d096beb7378794c6255dca2a866e6.diff
jhuber6 wrote:
> The build is failing because of a formatting error which I don't think is
> related to the changes that I made. Any thoughts as to why it is failing?
That's unrelated, I'll fix it.
https://github.com/llvm/llvm-project/pull/81015
___
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/81015
___
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/81015
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -21124,6 +21124,8 @@ Sema::ActOnOpenMPDependClause(const
OMPDependClause::DependDataTy ,
ExprTy = ATy->getElementType();
else
ExprTy = BaseType->getPointeeType();
+if (ExprTy.isNull())
+ continue;
jhuber6 wrote:
I'll merge it for you once the CI builder finishes without issue, thanks.
https://github.com/llvm/llvm-project/pull/81015
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/81015
___
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/80066
___
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/80066
___
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/80741
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -832,6 +832,13 @@ void test_atomic_inc_dec(local uint *lptr, global uint
*gptr, uint val) {
res = __builtin_amdgcn_atomic_dec32((volatile global uint*)gptr, val,
__ATOMIC_SEQ_CST, "");
}
+// CHECK-LABEL test_wavefrontsize(
+unsigned test_wavefrontsize() {
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/80741
Summary:
The backend supports the wavefrontsize intrinsic, and suggests that it
is tied to a corresponding clang builtin, but it is not actually
present. This simply adds it in so it can be used from clang. This
@@ -6872,35 +6883,6 @@ void OpenMPIRBuilder::loadOffloadInfoMetadata(StringRef
HostFilePath) {
loadOffloadInfoMetadata(*M.get());
}
-Function *OpenMPIRBuilder::createRegisterRequires(StringRef Name) {
jhuber6 wrote:
It was a very obvious problem. I mixed
Author: Joseph Huber
Date: 2024-02-05T09:08:31-06:00
New Revision: d1722868d34a69df8466b72098176f54a7af8823
URL:
https://github.com/llvm/llvm-project/commit/d1722868d34a69df8466b72098176f54a7af8823
DIFF:
https://github.com/llvm/llvm-project/commit/d1722868d34a69df8466b72098176f54a7af8823.diff
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/80183
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6872,35 +6883,6 @@ void OpenMPIRBuilder::loadOffloadInfoMetadata(StringRef
HostFilePath) {
loadOffloadInfoMetadata(*M.get());
}
-Function *OpenMPIRBuilder::createRegisterRequires(StringRef Name) {
jhuber6 wrote:
I encoded the fact that this is a
@@ -6872,35 +6883,6 @@ void OpenMPIRBuilder::loadOffloadInfoMetadata(StringRef
HostFilePath) {
loadOffloadInfoMetadata(*M.get());
}
-Function *OpenMPIRBuilder::createRegisterRequires(StringRef Name) {
jhuber6 wrote:
That looks a little weird, the `i32`
@@ -6872,35 +6883,6 @@ void OpenMPIRBuilder::loadOffloadInfoMetadata(StringRef
HostFilePath) {
loadOffloadInfoMetadata(*M.get());
}
-Function *OpenMPIRBuilder::createRegisterRequires(StringRef Name) {
jhuber6 wrote:
Thanks for the heads up. Do you know if
@@ -199,7 +199,7 @@ static int initLibrary(DeviceTy ) {
Entry.size) != OFFLOAD_SUCCESS)
REPORT("Failed to write symbol for USM %s\n", Entry.name);
}
-} else {
+} else if (Entry.addr) {
@@ -199,7 +199,7 @@ static int initLibrary(DeviceTy ) {
Entry.size) != OFFLOAD_SUCCESS)
REPORT("Failed to write symbol for USM %s\n", Entry.name);
}
-} else {
+} else if (Entry.addr) {
@@ -199,7 +199,7 @@ static int initLibrary(DeviceTy ) {
Entry.size) != OFFLOAD_SUCCESS)
REPORT("Failed to write symbol for USM %s\n", Entry.name);
}
-} else {
+} else if (Entry.addr) {
@@ -199,7 +199,7 @@ static int initLibrary(DeviceTy ) {
Entry.size) != OFFLOAD_SUCCESS)
REPORT("Failed to write symbol for USM %s\n", Entry.name);
}
-} else {
+} else if (Entry.addr) {
@@ -4,13 +4,10 @@
// RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx1010 -target-feature
-wavefrontsize64 -verify -S -o - %s
// RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx1010 -verify -S -o - %s
+// expected-no-diagnostics
+
typedef unsigned long ulong;
void
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/80183
>From 26b75cdba1aebc881e52dc82ca61e1082ef67a5e Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 31 Jan 2024 13:18:04 -0600
Subject: [PATCH] [AMDGPU] Allow w64 ballot to be used on w32 targets
Summary:
@@ -4,13 +4,10 @@
// RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx1010 -target-feature
-wavefrontsize64 -verify -S -o - %s
// RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx1010 -verify -S -o - %s
+// expected-no-diagnostics
+
typedef unsigned long ulong;
void
jhuber6 wrote:
> After this change is there any value in having two different builtins? You
> could just have one that always return 64 bits.
I personally think it would be better to just have the one, but I figured that
decision was made earlier and it would break backwards compatibility.
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/80190
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -151,7 +151,7 @@ BUILTIN(__builtin_amdgcn_mqsad_u32_u8, "V4UiWUiUiV4Ui",
"nc")
//===--===//
TARGET_BUILTIN(__builtin_amdgcn_ballot_w32, "ZUib", "nc", "wavefrontsize32")
@@ -151,7 +151,7 @@ BUILTIN(__builtin_amdgcn_mqsad_u32_u8, "V4UiWUiUiV4Ui",
"nc")
//===--===//
TARGET_BUILTIN(__builtin_amdgcn_ballot_w32, "ZUib", "nc", "wavefrontsize32")
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/80066
>From af382e03e41ef679c35a6126a1b131a7a8a28360 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 30 Jan 2024 15:34:22 -0600
Subject: [PATCH 1/5] [LinkerWrapper] Support relocatable linking for
offloading
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/80066
>From af382e03e41ef679c35a6126a1b131a7a8a28360 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 30 Jan 2024 15:34:22 -0600
Subject: [PATCH 1/4] [LinkerWrapper] Support relocatable linking for
offloading
https://github.com/jhuber6 approved this pull request.
Do we have any tests for this kind of stuff? We really should have some mock
ROCm installation in one of the `Inputs/` directories and then do
`--rocm-path=` or something.
https://github.com/llvm/llvm-project/pull/80190
jhuber6 wrote:
> > the idea is that it would be the desired effect if someone went out of
> > their way to do this GPU subset linking thing.
>
> That would only be true when someone owns the whole build. That will not be
> the case in practice. A large enough project is usually a bunch of
@@ -151,7 +151,7 @@ BUILTIN(__builtin_amdgcn_mqsad_u32_u8, "V4UiWUiUiV4Ui",
"nc")
//===--===//
TARGET_BUILTIN(__builtin_amdgcn_ballot_w32, "ZUib", "nc", "wavefrontsize32")
jhuber6 wrote:
> > I'm assuming you're talking about GPU-side constructors? I don't think the
> > CUDA runtime supports those, but OpenMP runs them when the image is loaded,
> > so it would handle both independantly.
>
> Yes. I'm thinking of the expectations from a C++ user standpoint, and
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/80183
Summary:
Currently we cannot compile `__builtin_amdgcn_ballot_w64` on non-wave64
targets even though it is valid. This is relevant for making library
code that can handle both without needing to check the
jhuber6 wrote:
> Supporting such mixed mode opens an interesting set of issues we may need to
> consider going forward:
>
> who/where/how runs initializers in the fully linked parts?
I'm assuming you're talking about GPU-side constructors? I don't think the CUDA
runtime supports those, but
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/80066
>From af382e03e41ef679c35a6126a1b131a7a8a28360 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 30 Jan 2024 15:34:22 -0600
Subject: [PATCH 1/3] [LinkerWrapper] Support relocatable linking for
offloading
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/80066
>From af382e03e41ef679c35a6126a1b131a7a8a28360 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 30 Jan 2024 15:34:22 -0600
Subject: [PATCH 1/2] [LinkerWrapper] Support relocatable linking for
offloading
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/80066
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> So, the idea is to carry two separate embedded offloading sections -- one for
> already fully linked GPU executables, and another for GPU objects to be
> linked at the final link stage.
>
It's more or less doing `-fno-gpu-rdc` on a subset of files. So you can do GPU
linking
401 - 500 of 1299 matches
Mail list logo
