shiltian wrote:
Isn't offload bundler a target agnostic tool?
> This could help us not break things internally, and then as tools and APIs
> update to V6, they can also update to 4-field triples
PSDB has full green. I also created issues to all repos that use
`clang-offload-bundler` binary di
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/104661
>From 5729891997dacfac91ad807ddfde60aec44708fb Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Fri, 17 Jan 2025 11:01:49 -0500
Subject: [PATCH] [Clang] Remove 3-element vector load and store special
handling
@@ -52,6 +52,17 @@ class AMDGPUABIInfo final : public DefaultABIInfo {
void computeInfo(CGFunctionInfo &FI) const override;
RValue EmitVAArg(CodeGenFunction &CGF, Address VAListAddr, QualType Ty,
AggValueSlot Slot) const override;
+
+ llvm::FixedVectorTy
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/104661
>From 68999359723466f762d3541359b1e55421e601fb Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Fri, 17 Jan 2025 10:55:59 -0500
Subject: [PATCH] [Clang] Remove 3-element vector load and store special
handling
shiltian wrote:
bump bump
https://github.com/llvm/llvm-project/pull/104661
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/104661
>From 06bb0e1c57e338923749826941c27b658338b540 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Thu, 16 Jan 2025 12:20:56 -0500
Subject: [PATCH] [Clang] Remove 3-element vector load and store special
handling
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/122629
>From 1b13d1465c90e3f6021628d723d807bdf4d155a8 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Thu, 16 Jan 2025 11:59:06 -0500
Subject: [PATCH] [OffloadBundler] Rework the ctor of `OffloadTargetInfo` to
suppo
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/122629
>From 2055d82d74bad8f1ffa7ee53e62617702556aec7 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Thu, 16 Jan 2025 08:46:19 -0500
Subject: [PATCH] [OffloadBundler] Rework the ctor of `OffloadTargetInfo` to
suppo
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/122629
>From 9966972ab344408f58ba156bd286ea44b4dad618 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Sun, 12 Jan 2025 18:01:55 -0500
Subject: [PATCH] [OffloadBundler] Rework the ctor of `OffloadTargetInfo` to
suppo
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/122629
>From c7c5b740c813afed4ab2c29ac4d4951d62a04bfc Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Tue, 14 Jan 2025 11:55:10 -0500
Subject: [PATCH 1/2] [LLVM][Triple] Add an argument to specify canonical form
to
shiltian wrote:
> So at least a few direct users this may break things for. There are also
> users that call the OffloadBundler API instead of directly calling
> clang-offload-bundler that this may impact.
For the API usage there will be no issue because we enforce it in the code
already. The
shiltian wrote:
> Could we assume "gfx * -generic" is a single Target ID, and check for/parse
> that separately before doing rsplit on "-"?
I was thinking about it the other day but eventually gave up on it, because I
want to keep this part as generic as possible instead of adding AMD special
shiltian wrote:
> Is there a way for us to still support 3-field triples and generic targets?
I can't come up with a better solution because we don't know how many `-` could
exist in the generic target id. With that, fixating the "known" part (aka
triple) would be reasonable. Do you have any s
shiltian wrote:
> Did you try this patch with internal PSDB? Does it break any existing HIP
> apps or libraries?
Will make a PR shortly after the migration.
https://github.com/llvm/llvm-project/pull/122629
___
cfe-commits mailing list
cfe-commits@lis
https://github.com/shiltian edited
https://github.com/llvm/llvm-project/pull/122629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/122629
>From 26ebaf07e5c6a8c3d8599fcbea3b7c947f31c943 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Sun, 12 Jan 2025 18:01:55 -0500
Subject: [PATCH] [OffloadBundler] Rework the ctor of `OffloadTargetInfo` to
suppo
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/122629
>From 2fdbbac7ca1dcb5b6a0ad28f9fedabf24c634465 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Sun, 12 Jan 2025 15:58:32 -0500
Subject: [PATCH] [OffloadBundler] Rework the ctor of `OffloadTargetInfo` to
suppo
https://github.com/shiltian edited
https://github.com/llvm/llvm-project/pull/122629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/shiltian edited
https://github.com/llvm/llvm-project/pull/122629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/122629
>From c58bbd1edcc295a03d68a311a16080550c6aea96 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Sun, 12 Jan 2025 10:48:56 -0500
Subject: [PATCH] [OffloadBundler] Rework the ctor of `OffloadTargetInfo` to
suppo
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/122629
>From b1dbe4f558fe282968af1ac33d58d74d3238d8d5 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Sun, 12 Jan 2025 10:48:56 -0500
Subject: [PATCH] [OffloadBundler] Rework the ctor of `OffloadTargetInfo` to
suppo
https://github.com/shiltian edited
https://github.com/llvm/llvm-project/pull/122629
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/shiltian closed
https://github.com/llvm/llvm-project/pull/122627
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
shiltian wrote:
### Merge activity
* **Jan 12, 10:49 AM EST**: A user started a stack merge that includes this
pull request via
[Graphite](https://app.graphite.dev/github/pr/llvm/llvm-project/122627).
https://github.com/llvm/llvm-project/pull/122627
__
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/122627
>From 71bad77117ef0dedbe6c28ff578470d8266108a6 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Sat, 11 Jan 2025 21:24:53 -0500
Subject: [PATCH] [Clang] Use `-targets=host-x86_64-unknown-linux-gnu` as
bundler
shiltian wrote:
* **#122627** https://app.graphite.dev/github/pr/llvm/llvm-project/122627?utm_source=stack-comment-icon";
target="_blank">https://static.graphite.dev/graphite-32x32-black.png"; alt="Graphite"
width="10px" height="10px"/> 👈 https://app.graphite.dev/github/pr/llvm/llvm-project/122
https://github.com/shiltian created
https://github.com/llvm/llvm-project/pull/122627
This a prime patch to support generic target when using `--offload-compress`.
>From 95332e05f381f7e80cd1c57420db0c56cf8aedcf Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Sat, 11 Jan 2025 21:24:53 -0500
Sub
@@ -52,6 +52,17 @@ class AMDGPUABIInfo final : public DefaultABIInfo {
void computeInfo(CGFunctionInfo &FI) const override;
RValue EmitVAArg(CodeGenFunction &CGF, Address VAListAddr, QualType Ty,
AggValueSlot Slot) const override;
+
+ llvm::FixedVectorTy
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/104661
>From ac2bd8cd5d9faf6c9a9ae7846b4110ade92d2f40 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Fri, 10 Jan 2025 12:25:03 -0500
Subject: [PATCH] [Clang] Remove 3-element vector load and store special
handling
Author: Shilei Tian
Date: 2025-01-10T12:22:25-05:00
New Revision: ac2d529be31d7a670326298036a4b9b3eaed59d3
URL:
https://github.com/llvm/llvm-project/commit/ac2d529be31d7a670326298036a4b9b3eaed59d3
DIFF:
https://github.com/llvm/llvm-project/commit/ac2d529be31d7a670326298036a4b9b3eaed59d3.diff
L
shiltian wrote:
> the target regions are just outlined, so it shouldn't affect anything on a
> codegen level.
No, they are not. The standard defines the execution behavior and codegen has
to conform with it. The current GPU CodeGen in this discussion assumes it is
generating for constructs _i
https://github.com/shiltian commented:
Do we have a clear idea on if a construct can behave in a different manner if
it is nested in a target region?
https://github.com/llvm/llvm-project/pull/122149
___
cfe-commits mailing list
cfe-commits@lists.llvm.
@@ -1312,6 +1309,19 @@ void CGOpenMPRuntimeGPU::emitBarrierCall(CodeGenFunction
&CGF,
Args);
}
+void CGOpenMPRuntimeGPU::emitTargetCall(
+CodeGenFunction &CGF, const OMPExecutableDirective &D,
+llvm::Function *OutlinedFn, llvm::Value *OutlinedFnI
https://github.com/shiltian edited
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
shiltian wrote:
> To me this looks like compilation for a host, except the GPU is the host. The
> only functions that could be called from such a CU would be the top-level
> ones, not any of the auto-generated one.
>
> Additionally, the host wouldn't support offload, so we'd need to do somethi
shiltian wrote:
> It should maintain the normal semantics you'd get with -fopenmp except it
> codegens certain things differently.
That is the key difference.
> Alternatively I could just remove OpenMP entirely from the DeviceRTL so I
> might just do that instead.
+1
https://github.com/llvm
shiltian wrote:
I think that is a misuse of OpenMP semantics. We can't expect to have regular
OpenMP code working in the same way as OpenMP offloading code when targeting a
GPU meanwhile while the code is not wrapped into `target` region. I understand
to have variants and declare target is not
shiltian wrote:
I don't think it should be GPU code generation path as there is no explicit
`target` region used.
https://github.com/llvm/llvm-project/pull/122149
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/m
shiltian wrote:
What code generation path would be used in this case? The GPU code generation
or regular host OpenMP?
https://github.com/llvm/llvm-project/pull/122149
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
https://github.com/shiltian approved this pull request.
https://github.com/llvm/llvm-project/pull/122143
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -31,8 +30,8 @@ void SYCLInstallationDetector::addSYCLIncludeArgs(
}
// Unsupported options for SYCL device compilation.
-static ArrayRef getUnsupportedOpts() {
- return {
+static ArrayRef getUnsupportedOpts() {
shiltian wrote:
maybe it's a good idea to re
shiltian wrote:
The fix doesn't look right to me...
https://github.com/llvm/llvm-project/pull/122047
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/104661
>From e4759cadf07aa883ca0d9ca8582dbd02fc028478 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Tue, 7 Jan 2025 13:20:00 -0500
Subject: [PATCH] [Clang] Remove 3-element vector load and store special
handling
https://github.com/shiltian edited
https://github.com/llvm/llvm-project/pull/104661
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -94,43 +94,43 @@ typedef double __attribute__((ext_vector_type(16)))
double16;
// CHECK-LABEL: @local_memory_alignment_global(
// CHECK: store volatile i8 0, ptr addrspace(3)
@local_memory_alignment_global.lds_i8, align 1
// CHECK: store volatile <2 x i8> zeroinitializer,
@@ -52,6 +52,12 @@ class AMDGPUABIInfo final : public DefaultABIInfo {
void computeInfo(CGFunctionInfo &FI) const override;
RValue EmitVAArg(CodeGenFunction &CGF, Address VAListAddr, QualType Ty,
AggValueSlot Slot) const override;
+
+ llvm::FixedVectorTy
@@ -1,77 +0,0 @@
-// RUN: %clang_cc1 %s -emit-llvm -o - -triple spir-unknown-unknown
-fpreserve-vec3-type | FileCheck %s
-
-typedef char char3 __attribute__((ext_vector_type(3)));
shiltian wrote:
The point of the test is for preserving vec3, as the name of the f
shiltian wrote:
ping @arsenm @topperc
https://github.com/llvm/llvm-project/pull/104661
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
shiltian wrote:
This PR introduced a new compile warning when compiling using clang. Please fix
it.
```
llvm-project/clang/lib/Driver/ToolChains/SYCL.cpp:35:10: warning: returning
address of local temporary object [-Wreturn-stack-address]
35 | return {
| ^
36 | opt
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/104661
>From 76db8c65328736fae39bd6f7585f8274e9f34143 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Tue, 17 Dec 2024 23:50:06 -0500
Subject: [PATCH] [Clang] Remove 3-element vector load and store special
handling
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/104661
>From 9dfb68ddc02bb70b3c9ff9d5aeedabbc2feed258 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Tue, 17 Dec 2024 23:50:06 -0500
Subject: [PATCH] [Clang] Remove 3-element vector load and store special
handling
Author: Shilei Tian
Date: 2024-12-29T22:28:14-05:00
New Revision: 49331ab0b9a41f925153fe03cd7e0d4a33b7c3d4
URL:
https://github.com/llvm/llvm-project/commit/49331ab0b9a41f925153fe03cd7e0d4a33b7c3d4
DIFF:
https://github.com/llvm/llvm-project/commit/49331ab0b9a41f925153fe03cd7e0d4a33b7c3d4.diff
L
@@ -2903,7 +2903,10 @@ TargetOMPContext::TargetOMPContext(
const FunctionDecl *CurrentFunctionDecl,
ArrayRef ConstructTraits)
: OMPContext(ASTCtx.getLangOpts().OpenMPIsTargetDevice,
- ASTCtx.getTargetInfo().getTriple()),
+ ASTCtx.getT
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/104661
>From f01858b4850cef77794959a36ec704e125838b73 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Mon, 16 Dec 2024 21:51:53 -0500
Subject: [PATCH] [Clang] Remove 3-element vector load and store special
handling
@@ -1846,6 +1846,16 @@ class TargetInfo : public TransferrableTargetInfo,
return std::make_pair(64, 64);
}
+ /// Returns the optimal vector type elements based on the provided vector
+ /// type. For example, on some targets, a vector with 3 elements may be
+ /// treat
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/104661
>From 9e23538a7cac72fe456fb039b5e0f321a0f3e142 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Mon, 16 Dec 2024 21:51:53 -0500
Subject: [PATCH] [Clang] Remove 3-element vector load and store special
handling
@@ -1,4 +1,5 @@
set(LLVM_LINK_COMPONENTS
+ Core
shiltian wrote:
> This shouldn't be necessary. I think this code is in the wrong place, I would
> expect it to go in lib/CodeGen/Targets, not lib/Basic
And then to have clang depend on LLVM's CodeGen component?
shiltian wrote:
gentle ping
https://github.com/llvm/llvm-project/pull/104661
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/shiltian edited
https://github.com/llvm/llvm-project/pull/119261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/shiltian edited
https://github.com/llvm/llvm-project/pull/119261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1270,77 +1270,21 @@ exit:
; MODULE: attributes #[[ATTR1:[0-9]+]] = { convergent nocallback nounwind }
; MODULE: attributes #[[ATTR2:[0-9]+]] = { convergent nocallback nofree
nounwind willreturn }
; MODULE: attributes #[[ATTR3:[0-9]+]] = { nocallback nofree nosync nounwind
@@ -1270,77 +1270,21 @@ exit:
; MODULE: attributes #[[ATTR1:[0-9]+]] = { convergent nocallback nounwind }
; MODULE: attributes #[[ATTR2:[0-9]+]] = { convergent nocallback nofree
nounwind willreturn }
; MODULE: attributes #[[ATTR3:[0-9]+]] = { nocallback nofree nosync nounwind
https://github.com/shiltian edited
https://github.com/llvm/llvm-project/pull/117904
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/shiltian edited
https://github.com/llvm/llvm-project/pull/117904
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -141,6 +141,12 @@ struct VariantMatchInfo {
ISATraits.push_back(RawString);
RequiredTraits.set(unsigned(Property));
+#if 0
shiltian wrote:
what is this for?
https://github.com/llvm/llvm-project/pull/117904
___
shiltian wrote:
@alexey-bataev What do you think? I'm not very familiar with some front end
concepts used in this PR.
https://github.com/llvm/llvm-project/pull/117904
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-b
https://github.com/shiltian commented:
update the openmp doc as well?
https://github.com/llvm/llvm-project/pull/117904
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/104661
>From 69d491983634adb2c059025ac848d1c53b0b282a Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Fri, 13 Dec 2024 08:59:59 -0500
Subject: [PATCH] [Clang] Remove 3-element vector load and store special
handling
https://github.com/shiltian edited
https://github.com/llvm/llvm-project/pull/104661
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/104661
>From e4b3028885112cd33206051292b3b397f90a3d5c Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Fri, 13 Dec 2024 00:38:50 -0500
Subject: [PATCH] [Clang] Remove 3-element vector load and store special
handling
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/104661
>From 007818c271c18d96c112fc1835b4175ab6d509f3 Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Fri, 13 Dec 2024 00:37:55 -0500
Subject: [PATCH] [Clang] Remove 3-element vector load and store special
handling
@@ -1,4 +1,5 @@
set(LLVM_LINK_COMPONENTS
+ Core
shiltian wrote:
This is needed because `TargetInfo.cpp` now needs LLVM types.
https://github.com/llvm/llvm-project/pull/104661
___
cfe-commits mailing list
cfe-commits@
@@ -1846,6 +1846,16 @@ class TargetInfo : public TransferrableTargetInfo,
return std::make_pair(64, 64);
}
+ /// Returns the optimal vector type elements based on the provided vector
+ /// type. For example, on some targets, a vector with 3 elements may be
+ /// treat
https://github.com/shiltian updated
https://github.com/llvm/llvm-project/pull/104661
>From c422624756e9b40b3fee02c6b3bb49d3355a1bbe Mon Sep 17 00:00:00 2001
From: Shilei Tian
Date: Fri, 13 Dec 2024 00:35:28 -0500
Subject: [PATCH] [Clang] Remove 3-element vector load and store special
handling
@@ -45,7 +45,7 @@ void test3(packedfloat3 *p) {
*p = (packedfloat3) { 3.2f, 2.3f, 0.1f };
}
// CHECK: @test3(
-// CHECK: store <4 x float> {{.*}}, align 4
+// CHECK: store <3 x float> {{.*}}, align 4
shiltian wrote:
`unsigned getOptimalVectorNumElements(cons
@@ -8026,10 +8026,6 @@ def fhlsl_strict_availability : Flag<["-"],
"fhlsl-strict-availability">,
Group,
MarshallingInfoFlag>;
-def fpreserve_vec3_type : Flag<["-"], "fpreserve-vec3-type">,
- HelpText<"Preserve 3-component vector type">,
- MarshallingInfoFlag>,
- Implie
@@ -45,7 +45,7 @@ void test3(packedfloat3 *p) {
*p = (packedfloat3) { 3.2f, 2.3f, 0.1f };
}
// CHECK: @test3(
-// CHECK: store <4 x float> {{.*}}, align 4
+// CHECK: store <3 x float> {{.*}}, align 4
shiltian wrote:
Eventually we might do it like:
```
bool
@@ -45,7 +45,7 @@ void test3(packedfloat3 *p) {
*p = (packedfloat3) { 3.2f, 2.3f, 0.1f };
}
// CHECK: @test3(
-// CHECK: store <4 x float> {{.*}}, align 4
+// CHECK: store <3 x float> {{.*}}, align 4
shiltian wrote:
I took another look and this is not only a
@@ -0,0 +1,11 @@
+// REQUIRES: asserts
+
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -target-cpu x86-64
-disable-llvm-passes -fopenmp-targets=amdgcn-amd-amdhsa -x c++ -emit-llvm-bc %s
-o %t-x86-host.bc
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -aux-triple
x86_64-un
shiltian wrote:
@krzysz00 Do you suggest that the actual value doesn't matter? Like, 128 is not
better or worse than 256.
https://github.com/llvm/llvm-project/pull/79035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cg
shiltian wrote:
What is the best case (from the compiler optimization perspective) that we can
expect from `amdgpu-max-num-workgroups`? For example, is a smaller value
better? I’d imagine that with a smaller value, the compiler can assume each
workgroup has access to more resources. If that’s
@@ -1270,77 +1270,21 @@ exit:
; MODULE: attributes #[[ATTR1:[0-9]+]] = { convergent nocallback nounwind }
; MODULE: attributes #[[ATTR2:[0-9]+]] = { convergent nocallback nofree
nounwind willreturn }
; MODULE: attributes #[[ATTR3:[0-9]+]] = { nocallback nofree nosync nounwind
https://github.com/shiltian edited
https://github.com/llvm/llvm-project/pull/119261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1270,77 +1270,21 @@ exit:
; MODULE: attributes #[[ATTR1:[0-9]+]] = { convergent nocallback nounwind }
; MODULE: attributes #[[ATTR2:[0-9]+]] = { convergent nocallback nofree
nounwind willreturn }
; MODULE: attributes #[[ATTR3:[0-9]+]] = { nocallback nofree nosync nounwind
@@ -5965,6 +5967,266 @@ static bool teamsLoopCanBeParallelFor(Stmt *AStmt, Sema
&SemaRef) {
return Checker.teamsLoopCanBeParallelFor();
}
+static Expr *getInitialExprFromCapturedExpr(Expr *Cond) {
+
+ Expr *SubExpr = Cond->IgnoreParenImpCasts();
+
+ if (auto *DeclRef = dy
@@ -5965,6 +5967,266 @@ static bool teamsLoopCanBeParallelFor(Stmt *AStmt, Sema
&SemaRef) {
return Checker.teamsLoopCanBeParallelFor();
}
+static Expr *getInitialExprFromCapturedExpr(Expr *Cond) {
+
+ Expr *SubExpr = Cond->IgnoreParenImpCasts();
+
+ if (auto *DeclRef = dy
@@ -5965,6 +5967,266 @@ static bool teamsLoopCanBeParallelFor(Stmt *AStmt, Sema
&SemaRef) {
return Checker.teamsLoopCanBeParallelFor();
}
+static Expr *getInitialExprFromCapturedExpr(Expr *Cond) {
+
+ Expr *SubExpr = Cond->IgnoreParenImpCasts();
+
+ if (auto *DeclRef = dy
@@ -5965,6 +5967,266 @@ static bool teamsLoopCanBeParallelFor(Stmt *AStmt, Sema
&SemaRef) {
return Checker.teamsLoopCanBeParallelFor();
}
+static Expr *getInitialExprFromCapturedExpr(Expr *Cond) {
+
+ Expr *SubExpr = Cond->IgnoreParenImpCasts();
+
+ if (auto *DeclRef = dy
@@ -5965,6 +5967,266 @@ static bool teamsLoopCanBeParallelFor(Stmt *AStmt, Sema
&SemaRef) {
return Checker.teamsLoopCanBeParallelFor();
}
+static Expr *getInitialExprFromCapturedExpr(Expr *Cond) {
+
+ Expr *SubExpr = Cond->IgnoreParenImpCasts();
+
+ if (auto *DeclRef = dy
@@ -10520,11 +10794,22 @@ StmtResult
SemaOpenMP::ActOnOpenMPSectionDirective(Stmt *AStmt,
DSAStack->isCancelRegion());
}
+/// PseudoObjectExpr is a Trait for dispatch containing the
+/// function and its variant. Returning only the functio
@@ -5979,6 +6241,17 @@ StmtResult SemaOpenMP::ActOnOpenMPExecutableDirective(
OMPExecutableDirective::getSingleClause(Clauses))
BindKind = BC->getBindKind();
+ if ((Kind == OMPD_dispatch) && (Clauses.size() > 0)) {
shiltian wrote:
```suggestion
@@ -7209,8 +7482,9 @@ ExprResult SemaOpenMP::ActOnOpenMPCall(ExprResult Call,
Scope *Scope,
Exprs.erase(Exprs.begin() + BestIdx);
} while (!VMIs.empty());
- if (!NewCall.isUsable())
+ if (!NewCall.isUsable()) {
return Call;
+ }
shiltian wrote:
@@ -10556,15 +10841,18 @@
SemaOpenMP::ActOnOpenMPDispatchDirective(ArrayRef Clauses,
E = E->IgnoreParenCasts()->IgnoreImplicit();
if (auto *BO = dyn_cast(E)) {
- if (BO->getOpcode() == BO_Assign)
+ if (BO->getOpcode() == BO_Assign) {
TargetCall = ge
https://github.com/shiltian edited
https://github.com/llvm/llvm-project/pull/117904
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
shiltian wrote:
> The IR is a representation of what goes on a final .o. It is not really
> intended to enable new features or make the program portable.
My .02 is, it depends on how to think about it. If we eliminate the "unwanted"
part (especially those that could potentially affect ABI) at
shiltian wrote:
> This probably should retain separate wave32/wave64 builds. Additionally,
> should have extension points for subtarget specific implementations
Does wave32/wave64 affect the lowering from front end source code to middle end
IR, if we don't use certain functions, such as wave l
https://github.com/shiltian approved this pull request.
it seems like there are some test failures but I think the PR looks good
https://github.com/llvm/llvm-project/pull/119091
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
shiltian wrote:
Worth a bullet point in release note, both clang and openmp/offload.
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
shiltian wrote:
> > I like this method, but just out of curiosity, did we use anything in
> > AMDGPU implementation that has target dependent lowering in the front end?
> > If not, this is totally fine I'd say.
>
> We used to use the `__AMDGCN_WAVEFRONT_SIZE` but that was removed for
> unrela
@@ -74,49 +72,53 @@ static int32_t nvptx_parallel_reduce_nowait(void
*reduce_data,
uint32_t NumThreads = omp_get_num_threads();
if (NumThreads == 1)
return 1;
-/*
- * This reduce function handles reduction within a team. It handles
- * parallel regions in b
1 - 100 of 819 matches
Mail list logo
