MrSidims wrote:
> You could make an extension to disable this feature instead of putting it in
> the compiler I'd think.
By introducing an extension one introduces a new language-visible semantics.
Outlining kernel implementation is neither new kernel language construct nor
new host API.
So
https://github.com/MrSidims closed
https://github.com/llvm/llvm-project/pull/140253
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MrSidims updated
https://github.com/llvm/llvm-project/pull/140253
>From 67935acd84b032209d45bad22db8e1a9e72c1dcd Mon Sep 17 00:00:00 2001
From: "Sidorov, Dmitry"
Date: Fri, 16 May 2025 06:55:10 -0700
Subject: [PATCH 1/3] [Clang] Allow vector and matrix type attributes for
su
https://github.com/MrSidims updated
https://github.com/llvm/llvm-project/pull/140253
>From 67935acd84b032209d45bad22db8e1a9e72c1dcd Mon Sep 17 00:00:00 2001
From: "Sidorov, Dmitry"
Date: Fri, 16 May 2025 06:55:10 -0700
Subject: [PATCH 1/2] [Clang] Allow vector and matrix type attributes for
su
MrSidims wrote:
> "tests would be a PITA to write, so lets restrict it and let someone who
> cares loosen it"
Yeah, that is understandable, I pushed the PR without extended tests just to
check, if there won't be immediate objections before committing time to write
them.
Soo... I have extende
https://github.com/MrSidims edited
https://github.com/llvm/llvm-project/pull/140253
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -571,6 +571,41 @@ void VectorTest(uint16_t4 first, uint16_t4 second) {
// CHECK: %[[ADD:.+]] = add <3 x i16> %[[Shuffle]], %[[Shuffle1]]
}
+typedef unsigned _BitInt(4) uint4_t4 __attribute__((ext_vector_type(4)));
+void VectorTest(uint4_t4 first, uint4_t4 second) {
+ //
@@ -571,6 +571,41 @@ void VectorTest(uint16_t4 first, uint16_t4 second) {
// CHECK: %[[ADD:.+]] = add <3 x i16> %[[Shuffle]], %[[Shuffle1]]
}
+typedef unsigned _BitInt(4) uint4_t4 __attribute__((ext_vector_type(4)));
+void VectorTest(uint4_t4 first, uint4_t4 second) {
+ //
https://github.com/MrSidims updated
https://github.com/llvm/llvm-project/pull/140253
>From 67935acd84b032209d45bad22db8e1a9e72c1dcd Mon Sep 17 00:00:00 2001
From: "Sidorov, Dmitry"
Date: Fri, 16 May 2025 06:55:10 -0700
Subject: [PATCH 1/2] [Clang] Allow vector and matrix type attributes for
su
MrSidims wrote:
> So I'd need to see some codegen tests that show that we're doing the right
> thing for these, plus some sort of testing that shows that we do the right
> thing with llvm codegen.
Sure, I'll work on this.
https://github.com/llvm/llvm-project/pull/140253
__
https://github.com/MrSidims edited
https://github.com/llvm/llvm-project/pull/140253
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MrSidims wrote:
@erichkeane @AaronBallman please take a look. Limitation that currently clang
has seem to be unreasonable. Currently I'm just removing it, but I'm open to
introducing a flag, that suppresses the error or make this error be a warning.
https://github.com/llvm/llvm-project/pull/14
https://github.com/MrSidims created
https://github.com/llvm/llvm-project/pull/140253
None
>From 67935acd84b032209d45bad22db8e1a9e72c1dcd Mon Sep 17 00:00:00 2001
From: "Sidorov, Dmitry"
Date: Fri, 16 May 2025 06:55:10 -0700
Subject: [PATCH] [Clang] Allow vector and matrix type attributes for s
https://github.com/MrSidims approved this pull request.
This change is LGTM, but I'm starting to wonder, if those maps (with the only
difference in default) can be unified and `setAddressSpaceMap` function changed
appropriately.
https://github.com/llvm/llvm-project/pull/137187
___
https://github.com/MrSidims approved this pull request.
https://github.com/llvm/llvm-project/pull/136753
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -fopenmp -x c++ -triple x86_64-unknown-unknown
-fopenmp-targets=spirv64 -emit-llvm-bc %s -o %t-host.bc
+// RUN: %clang_cc1 -fopenmp -fopenmp-targets=spirv64 -fopenmp-is-target-device
-triple spirv64 -fopenmp-host-ir-file-path %t-host.bc -emit
MrSidims wrote:
> this change makes sense and it doesn't bring (known to me) regressions
Actually, there is an incorrect behavior in the following test case:
https://godbolt.org/z/dc3T7Mo3G , note __clang_ocl_kern_imp_sample_kernel_float
was generated, but was never called. @lalaniket8 can thi
MrSidims wrote:
> This is the lowering to the target.
My glossary might not be lacking some definitions, but what I really meant by
lowering is:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AMDGPU or
https://github.com/llvm/llvm-project/tree/main/llvm/lib/Target/SPIRV .
I d
MrSidims wrote:
@lalaniket8 @arsenm I don't have a strong opinion, but shouldn't this
transformation be done during lowering to the target? Current version of the
patch brings odd behavior for LLVM IR to SPIR-V lowering for OpenCL kernels.
SPIR-V don't allow one EntryPoint to refer another Ent
MrSidims wrote:
Hi @ZijunZhaoCCK , sorry, I'm quite late for the party, but may I ask you some
questions?
We want to be able to distinguish between Vulkan and OpenCL environments in
[SPIR-V
backend](https://github.com/intel/llvm/tree/sycl/llvm/lib/Target/SPIRV), so we
could be able to pick b
MrSidims wrote:
> Thank you for the feedback! I might not be getting the question right (case
> in which I apologise in advance!), but I think that for "vanilla" SPIR-V i.e.
> not vendor flavoured one, where one strictly has to deal with Extensions /
> non-core capabilities, we probably would
https://github.com/MrSidims edited
https://github.com/llvm/llvm-project/pull/131190
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,501 @@
+//===- LowerGPUIntrinsic.cpp
--===//
+//
+// 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/MrSidims edited
https://github.com/llvm/llvm-project/pull/131190
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MrSidims edited
https://github.com/llvm/llvm-project/pull/131190
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MrSidims edited
https://github.com/llvm/llvm-project/pull/131190
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MrSidims edited
https://github.com/llvm/llvm-project/pull/131190
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MrSidims edited
https://github.com/llvm/llvm-project/pull/131190
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,501 @@
+//===- LowerGPUIntrinsic.cpp
--===//
+//
+// 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/MrSidims approved this pull request.
https://github.com/llvm/llvm-project/pull/129545
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MrSidims approved this pull request.
https://github.com/llvm/llvm-project/pull/122995
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MrSidims approved this pull request.
https://github.com/llvm/llvm-project/pull/120266
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MrSidims wrote:
I agree with Sven. We mustn't reuse llvm-spirv's tests format in other
repositories.
https://github.com/llvm/llvm-project/pull/120266
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listi
Nathan =?utf-8?q?Gauër?=
Message-ID:
In-Reply-To:
https://github.com/MrSidims edited
https://github.com/llvm/llvm-project/pull/116636
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Nathan =?utf-8?q?Gau=C3=ABr?=
Message-ID:
In-Reply-To:
https://github.com/MrSidims approved this pull request.
LGTM
Guess the PR description should be updated
https://github.com/llvm/llvm-project/pull/116636
___
cfe-commits mailing list
cfe-commits@
@@ -193,6 +194,33 @@ void AMDGCN::Linker::constructLldCommand(Compilation &C,
const JobAction &JA,
Lld, LldArgs, Inputs, Output));
}
+// For SPIR-V the inputs for the job are device AMDGCN SPIR-V flavoured bitcode
+// and the output is
@@ -193,6 +194,33 @@ void AMDGCN::Linker::constructLldCommand(Compilation &C,
const JobAction &JA,
Lld, LldArgs, Inputs, Output));
}
+// For SPIR-V the inputs for the job are device AMDGCN SPIR-V flavoured bitcode
+// and the output is
MrSidims wrote:
> InstCombine's primary function is a canonicalization pass. You shouldn't be
> modifying it for specifically SPIRV optimizations (with the exception of
> SPIRV intrinsic support). SPIRV specific transforms belong in later backend
> IR passes
Does it mean, that the reasoning b
https://github.com/MrSidims approved this pull request.
https://github.com/llvm/llvm-project/pull/110695
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
MrSidims wrote:
Don't get me wrong, what I'm saying is not an objection against the patch, but
rather an attempt to test the waters :)
https://github.com/llvm/llvm-project/pull/110695
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lis
MrSidims wrote:
> with vanilla upstream, please see
You mean the translator, right? I don't think that SPIR-V backend should follow
its practices especially when we could do better.
> At a glance, it seems like an issue around handling vec3s, which are odd,
> but, probably; the BE should prob
MrSidims wrote:
> You want spirv, not spir
Thanks! Yet the result is the same.
> Do you plan to go over LLVM passes adding this check?
So guess answer to my question would be: "no" :)
https://github.com/llvm/llvm-project/pull/110695
___
cfe-commits
MrSidims wrote:
> There's nothing new to do here. This has always existed
@arsenm here is a small experiment, I've compiled the following OpenCL code:
```
struct S {
char i8_3[3];
};
kernel void test(global struct S *p, float3 v)
{
int3 tmp;
frexp(v, &tmp);
tmp += 1;
p->i8_3[0]
https://github.com/MrSidims commented:
Thanks, it should make LLVM IR after optimizations more translatable in SPIR-V!
Few questions though:
1. Usually (or at least AFAIK) optimization passes won't consider datalayout
automatically, as LLVM defines datalayout not as a contract set by the
front
https://github.com/MrSidims edited
https://github.com/llvm/llvm-project/pull/106429
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/MrSidims edited
https://github.com/llvm/llvm-project/pull/106429
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -58,7 +58,35 @@ class SPIRVTargetCodeGenInfo : public
CommonSPIRTargetCodeGenInfo {
SPIRVTargetCodeGenInfo(CodeGen::CodeGenTypes &CGT)
: CommonSPIRTargetCodeGenInfo(std::make_unique(CGT)) {}
void setCUDAKernelCallingConvention(const FunctionType *&FT) const overri
https://github.com/MrSidims edited
https://github.com/llvm/llvm-project/pull/106429
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -251,6 +251,24 @@ SPIRV::MemorySemantics::MemorySemantics
getMemSemantics(AtomicOrdering Ord) {
llvm_unreachable(nullptr);
}
+SPIRV::Scope::Scope getMemScope(const LLVMContext &Ctx, SyncScope::ID ID) {
+ SmallVector SSNs;
+ Ctx.getSyncScopeNames(SSNs);
+
+ StringRef M
MrSidims wrote:
Tagging @svenvh to be aware of the discussion. I personally don't have a strong
opinion at the moment of what should be a default. Currently [SPIR-V To LLVM
translator](https://github.com/KhronosGroup/SPIRV-LLVM-Translator) picks
"Device" as the default (translation of the atom
50 matches
Mail list logo
