@@ -1309,6 +1309,13 @@ Sema::CheckOverload(Scope *S, FunctionDecl *New, const
LookupResult &Old,
return Ovl_Overload;
}
+template static bool hasExplicitAttr(const FunctionDecl *D) {
+ assert(D && "function delc should not be null");
Artem-B wrote:
`delc
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/121986
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1595,8 +1606,21 @@ static bool IsOverloadOrOverrideImpl(Sema &SemaRef,
FunctionDecl *New,
// Allow overloading of functions with same signature and different
CUDA
// target attributes.
-if (NewTarget != OldTarget)
+if (NewTarget != OldTarg
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/122155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -10,8 +10,14 @@
// CHECK-NEXT:[[TMP0:%.*]] = load ptr, ptr [[RET_ADDR]], align 8
// CHECK-NEXT:store i32 1, ptr [[TMP0]], align 4
// CHECK-NEXT:ret void
+//
__attribute__((nvptx_kernel)) void foo(int *ret) {
*ret = 1;
}
-// CHECK: !0 = !{ptr @foo, !"kernel
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/120806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Artem-B wrote:
> A 2% improvement is an excellent result!
LLVM caches these attributes these days. Before we've implemented that, nvvm
metadata lookups did take a lot of time.
That said, CC and attributes are a better way to represent the info, and
getting rid of the metadata is worthwhile ev
@@ -1595,8 +1606,21 @@ static bool IsOverloadOrOverrideImpl(Sema &SemaRef,
FunctionDecl *New,
// Allow overloading of functions with same signature and different
CUDA
// target attributes.
-if (NewTarget != OldTarget)
+if (NewTarget != OldTarg
@@ -1,13 +1,6 @@
-// RUN: %clang -cc1 -fcuda-is-device -isysroot /var/empty \
-// RUN: -triple nvptx-nvidia-cuda -aux-triple i386-apple-macosx \
-// RUN: -E -fcuda-is-device -v -o /dev/null -x cuda %s 2>&1 | FileCheck %s
-
-// RUN: %clang -cc1 -isysroot /var/empty \
-// RUN:
https://github.com/Artem-B 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
@@ -324,14 +326,15 @@ MaybeAlign getAlign(const Function &F, unsigned Index) {
F.getAttributes().getAttributes(Index).getStackAlignment())
return StackAlign;
- // If that is missing, check the legacy nvvm metadata
- std::vector Vs;
- bool retval = findAllNVVMA
@@ -5022,6 +5022,69 @@ bool llvm::UpgradeDebugInfo(Module &M) {
return Modified;
}
+bool static upgradeSingleNVVMAnnotation(GlobalValue *GV, StringRef K,
+const Metadata *V) {
+ if (K == "kernel") {
+assert(mdconst::extract(V)->ge
@@ -324,14 +326,17 @@ MaybeAlign getAlign(const Function &F, unsigned Index) {
F.getAttributes().getAttributes(Index).getStackAlignment())
return StackAlign;
- // If that is missing, check the legacy nvvm metadata
- std::vector Vs;
- bool retval = findAllNVVMA
@@ -5022,6 +5022,69 @@ bool llvm::UpgradeDebugInfo(Module &M) {
return Modified;
}
+bool static upgradeSingleNVVMAnnotation(GlobalValue *GV, StringRef K,
+const Metadata *V) {
+ if (K == "kernel") {
+assert(mdconst::extract(V)->ge
@@ -5022,6 +5022,69 @@ bool llvm::UpgradeDebugInfo(Module &M) {
return Modified;
}
+bool static upgradeSingleNVVMAnnotation(GlobalValue *GV, StringRef K,
+const Metadata *V) {
+ if (K == "kernel") {
+assert(mdconst::extract(V)->ge
@@ -5022,6 +5022,69 @@ bool llvm::UpgradeDebugInfo(Module &M) {
return Modified;
}
+bool static upgradeSingleNVVMAnnotation(GlobalValue *GV, StringRef K,
+const Metadata *V) {
+ if (K == "kernel") {
+assert(mdconst::extract(V)->ge
@@ -10,7 +10,7 @@
extern "C"
__device__ void device_function() {}
-// CHECK-LABEL: define{{.*}} void @global_function
+// CHECK: define{{.*}} void @global_function{{.*}} #[[ATTR0:[0-9]+]]
Artem-B wrote:
It should still be `CHECK-LABEL`
You could split attribu
https://github.com/Artem-B commented:
Few nits. LGTM overall, except for the "kernel/nvvm.kernel" distinction
question.
https://github.com/llvm/llvm-project/pull/119261
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/c
@@ -5022,6 +5022,69 @@ bool llvm::UpgradeDebugInfo(Module &M) {
return Modified;
}
+bool static upgradeSingleNVVMAnnotation(GlobalValue *GV, StringRef K,
+const Metadata *V) {
+ if (K == "kernel") {
+assert(mdconst::extract(V)->ge
@@ -5911,31 +5911,21 @@ bool llvm::omp::isOpenMPKernel(Function &Fn) {
KernelSet llvm::omp::getDeviceKernels(Module &M) {
// TODO: Create a more cross-platform way of determining device kernels.
- NamedMDNode *MD = M.getNamedMetadata("nvvm.annotations");
KernelSet Kernel
https://github.com/Artem-B 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
@@ -302,6 +299,19 @@ void NVPTXTargetCodeGenInfo::addNVVMMetadata(
llvm::ConstantAsMetadata::get(GV), llvm::MDString::get(Ctx, Name),
llvm::ConstantAsMetadata::get(
llvm::ConstantInt::get(llvm::Type::getInt32Ty(Ctx), Operand))};
+ // Append metadata to nv
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/117415
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Artem-B wrote:
I am surprised that this is needed. I suspect clang picks the default CUDA
version on your machine.
While `--no-cuda-version-check` will make the test work, it will still pick
CUDA installation ourside of the source tree, and then suppress the error.
A better way to fix this ma
https://github.com/Artem-B closed
https://github.com/llvm/llvm-project/pull/117361
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Artem-B created
https://github.com/llvm/llvm-project/pull/117361
None
>From 394ef51560731ae1f42fd049655dde1ce2d11a1e Mon Sep 17 00:00:00 2001
From: Artem Belevich
Date: Fri, 22 Nov 2024 10:50:50 -0800
Subject: [PATCH] [HIP] Fix tests broken by #117074 / 689c532
---
clang/t
Artem-B wrote:
Darn. I've missed additional HIP tests. I'll fix the test failures shortly.
https://github.com/llvm/llvm-project/pull/117074
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
https://github.com/Artem-B closed
https://github.com/llvm/llvm-project/pull/117074
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Artem-B wrote:
Done.
https://github.com/llvm/llvm-project/pull/117074
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Artem-B updated
https://github.com/llvm/llvm-project/pull/117074
>From 1c8829a1defa6dd06aacb9a2047e7f79db238e2b Mon Sep 17 00:00:00 2001
From: Artem Belevich
Date: Wed, 20 Nov 2024 14:24:00 -0800
Subject: [PATCH 1/2] [CUDA] pass -fno-threadsafe-statics to GPU
sub-compilation
https://github.com/Artem-B created
https://github.com/llvm/llvm-project/pull/117074
We do not have support for the threadsafe statics on the GPU side.
However, we do sometimes end up with empty local static initializers, and those
happen to trigger calls to `__cxa_guard*`, which breaks compila
Artem-B wrote:
@yxsamliu -- should I add it for HIP, too?
https://github.com/llvm/llvm-project/pull/117074
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Artem-B wrote:
The patch request has been already approved. Nothing seems to have changed
since then to the patch?
Are you asking for help landing the patch?
https://github.com/llvm/llvm-project/pull/114056
___
cfe-commits mailing list
cfe-commits@lis
https://github.com/Artem-B closed
https://github.com/llvm/llvm-project/pull/114056
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Artem-B wrote:
While I'm not sure how concepts will work in CUDA in the end, I'm OK with
fixing obviously wrong behaviors now, without potentially paining ourselves
into a corner.
The key issue in the example in https://godbolt.org/z/o7Wa68n9c seems to be
that CUDA's context-aware overload res
Artem-B 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,
you would hav
Artem-B 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. OpenCL sort o
https://github.com/Artem-B closed
https://github.com/llvm/llvm-project/pull/114589
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Artem-B updated
https://github.com/llvm/llvm-project/pull/114589
>From ac0790a431d94f78ee73e96fd97f9263192c3153 Mon Sep 17 00:00:00 2001
From: Artem Belevich
Date: Tue, 27 Aug 2024 16:16:14 -0700
Subject: [PATCH 1/2] [CUDA] Add support for __grid_constant__ attribute
---
cl
@@ -1450,6 +1450,13 @@ def CUDAHost : InheritableAttr {
}
def : MutualExclusions<[CUDAGlobal, CUDAHost]>;
+def CUDAGridConstant : InheritableAttr {
+ let Spellings = [GNU<"grid_constant">, Declspec<"__grid_constant__">];
+ let Subjects = SubjectList<[ParmVar]>;
+ let LangOp
@@ -1,8 +1,17 @@ bool Sema::CheckFunctionDeclaration(Scope *S,
FunctionDecl *NewFD,
<< NewFD;
}
-if (!Redeclaration && LangOpts.CUDA)
+if (!Redeclaration && LangOpts.CUDA) {
Artem-B wrote:
My mental model of whether we should
@@ -1,8 +1,17 @@ bool Sema::CheckFunctionDeclaration(Scope *S,
FunctionDecl *NewFD,
<< NewFD;
}
-if (!Redeclaration && LangOpts.CUDA)
+if (!Redeclaration && LangOpts.CUDA) {
Artem-B wrote:
I deliberately decided *not* to do th
Artem-B wrote:
I'm saying is that whatever refers to the fatbin handle has to have the same
idea about the name of that handle as the object file that provides that
handle. For that both have to be compiled with the same `cuid`. Normally, it's
clang driver that does that all under the hood. If
@@ -1093,6 +1097,169 @@ inline void FPOptions::applyChanges(FPOptionsOverride
FPO) {
*this = FPO.applyOverrides(*this);
}
+/// Atomic control options
+class AtomicOptionsOverride;
+class AtomicOptions {
+public:
+ using storage_type = uint16_t;
+
+ static constexpr unsign
https://github.com/Artem-B approved this pull request.
LGTM.
https://github.com/llvm/llvm-project/pull/114843
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Artem-B created
https://github.com/llvm/llvm-project/pull/114589
LLVM support for the attribute has been implemented already, so it just plumbs
it through to the CUDA front-end.
One notable difference from NVCC is that the attribute can be used regardless
of the targeted GP
Artem-B wrote:
> now it is complaining about __hip_fatbin earlier it was
> __hip_gpubin_handle_2ba9067058fbe93a.
In both cases there's some sort of inconsistency in your build. Find the
compilation which creates the object file which refers to the missing symbol,
and then we can try figuring
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/114056
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -91,12 +91,14 @@ __device__ inline void operator delete[](void *ptr,
#endif
// Device overrides for placement new and delete.
+#if _LIBCPP_STD_VER < 26
Artem-B wrote:
Yup. Reproducible on compiler explorer: https://godbolt.org/z/xr5nEhGnr
https://github.c
@@ -91,12 +91,14 @@ __device__ inline void operator delete[](void *ptr,
#endif
// Device overrides for placement new and delete.
+#if _LIBCPP_STD_VER < 26
Artem-B wrote:
This helps with libc++.
Do we run into this issue with libstdc++, too? If so, we may ch
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/113934
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Artem-B closed
https://github.com/llvm/llvm-project/pull/100247
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Artem-B wrote:
Closing the patch now, as we've figured out a way to move forward with simpler
changes.
https://github.com/llvm/llvm-project/pull/100247
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
https://github.com/Artem-B edited
https://github.com/llvm/llvm-project/pull/113017
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -363,6 +363,14 @@ void NVPTXInstPrinter::printMemOperand(const MCInst *MI,
int OpNum,
}
}
+void NVPTXInstPrinter::printOffseti32imm(const MCInst *MI, int OpNum,
+ raw_ostream &O, const char *Modifier)
{
+ if (auto &Op = MI->getOp
https://github.com/Artem-B approved this pull request.
LGTM overall, with a minor style nit.
https://github.com/llvm/llvm-project/pull/113017
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-c
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/111712
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Artem-B approved this pull request.
LGTM. Please add a note about the intrinsic removal/deprecation to the release
notes.
https://github.com/llvm/llvm-project/pull/112834
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https
https://github.com/Artem-B closed
https://github.com/llvm/llvm-project/pull/112028
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Artem-B updated
https://github.com/llvm/llvm-project/pull/112028
>From 17989b287b28fa1234dc7aca726f973086b687f2 Mon Sep 17 00:00:00 2001
From: Sergey Kozub
Date: Tue, 2 Jul 2024 02:44:56 -0700
Subject: [PATCH 1/2] [CUDA] Add support for CUDA-12.6 and sm_100
---
clang/docs/R
https://github.com/Artem-B updated
https://github.com/llvm/llvm-project/pull/112028
>From 5dac14aab180fd965d996b47cf983b8c462fe703 Mon Sep 17 00:00:00 2001
From: Sergey Kozub
Date: Tue, 2 Jul 2024 02:44:56 -0700
Subject: [PATCH 1/2] [CUDA] Add support for CUDA-12.6 and sm_100
---
clang/docs/R
https://github.com/Artem-B updated
https://github.com/llvm/llvm-project/pull/112028
>From 5dac14aab180fd965d996b47cf983b8c462fe703 Mon Sep 17 00:00:00 2001
From: Sergey Kozub
Date: Tue, 2 Jul 2024 02:44:56 -0700
Subject: [PATCH] [CUDA] Add support for CUDA-12.6 and sm_100
---
clang/docs/Relea
https://github.com/Artem-B created
https://github.com/llvm/llvm-project/pull/112028
This is a copy of #97402, which is now ready to land.
>From 8f2122e6ff890320d66e6d9f3cc5327b897c25e9 Mon Sep 17 00:00:00 2001
From: Sergey Kozub
Date: Tue, 2 Jul 2024 02:44:56 -0700
Subject: [PATCH] [CUDA] Add
@@ -1,13 +1,15 @@
// Check CUID generated by hash.
// The same CUID is generated for the same file with the same options.
+// RUN: cd %S
+
// RUN: %clang -### -x hip --target=x86_64-unknown-linux-gnu
--no-offload-new-driver \
// RUN: --offload-arch=gfx906 -c -nogpuinc -no
Artem-B wrote:
> I'm not sure why the option isn't enabled by default, personally
While it does indeed help with generating better code, using this option while
compiling CUDA code may be problematic.
Front-end is not aware of address spaces and all pointers are generic, so
`sizeof(any pointer
@@ -16,15 +18,15 @@
// RUN: %clang -### -x hip --target=x86_64-unknown-linux-gnu -DX=1
--no-offload-new-driver \
// RUN: --offload-arch=gfx906 -c -nogpuinc -nogpulib -fuse-cuid=hash \
-// RUN: %S/Inputs/hip_multiple_inputs/a.cu >%t.out 2>&1
+// RUN: Inputs/hip_multiple_
Artem-B wrote:
> This does not seem to be the right fix. I tends to think the test
> https://github.com/ROCm/hip-tests/tree/amd-staging/samples/2_Cookbook/16_assembly_to_executable
> needs fix. Since it does not expect host-only compilation to use CUID, it
> should add `-fuse-cuid=none` to the
Artem-B wrote:
Unless HIP explicitly defines wavefront size property for the host (I do not
think so), it would appear that it's a property of a GPU, and as such should
not be treated as a constant on the host, because the host needs to deal with
multiple GPU variants, with different idea of t
Artem-B wrote:
@ritter-x2a That's an outline of a strawman plan in case one does nave
nontrivial amount of existing code that depends on this macro, and assuming
that we still want to have a host-side macro for the wavefront size. If the end
goal is not to have the host-side macro at all, then
Artem-B wrote:
> I don't think we should rely on these on the host at all, the addition was a
> design mistake initially, we probably should not double down on it.
I agree with it in principle. However, removing things that already exist
should be done with consideration for the existing user
Artem-B wrote:
> This patch checks for numeric literals in clearly identifiable host code if
> they are the result of expanding the wavefront-size macros and issues a
> diagnostic if that's the case.
What's the ultimate goal here? If we're OK to warn on some obvious misuses,
then it may do.
Artem-B wrote:
I'm curious why are those macros even defined on the host?
It looks like these macros should be handled in a way similar to `__HIP_ARCH__`.
https://github.com/llvm/llvm-project/pull/109663
___
cfe-commits mailing list
cfe-commits@lists
@@ -0,0 +1,109 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: %clang -xhip --offload-arch=gfx1030 --offload-host-only -pedantic
-nogpuinc -nogpulib -nobuiltininc -fsyntax-only -Xclang -verify=onhost %s
+// RUN: %clang -xhip --offload-arch=gfx1030 --offload-device-only -pedant
Artem-B wrote:
> In this case, _ZL4cxxx does not have externally_initialized . If this patch
> does not remove externally_initialized, probably this constant propagation
> won't happen.
Indeed, unoptimized code shows that `cxxx` has no `externally_initialized`,
only `constant`.
If we keep e
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/110182
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Artem-B wrote:
It has nothing to do with writing to those arrays while the kernel is running.
That would indeed be UB.
> both would still work just the same even with this change,
No, they will not. Here's the demonstration of the behavior change that `const`
brings to the table:
https://cuda
Artem-B wrote:
Well, it's certainly used that way in existing CUDA code and it's been around
forever:
Here are few random examples from both 10 years ago:
https://stackoverflow.com/questions/20535683/cuda-5-5-cudamemcpytosymbol-constant-and-out-of-scope-error
and a fairly recent example:
https
Artem-B wrote:
I'm not 100% sure that `externally_initialized` is sufficient to deal with this
use pattern.
IR manual says: https://llvm.org/docs/LangRef.html#global-variables
> By default, global initializers are optimized by assuming that global
> variables defined within the module are not
Artem-B wrote:
`__constant__` may not necessarily be `const` for IR purposes. I.e. IR may not
rely on the 'known' values, as seen in IR, as the data may actually be
populated by the host via CUDA API calls `cudaMemcpyToSymbol` before the GPU
kernel launch.
https://github.com/llvm/llvm-project
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/110139
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Artem-B wrote:
@rnk Are symlinks OK to use on windows?
https://github.com/llvm/llvm-project/pull/110139
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Artem-B wrote:
> I'm still concerned about the (no-)aliasing guarantees. It's useful to have
> two non-flat address spaces that can alias,
Another example for NVIDIA GPUs would be `.param` space. According to the [PTX
spec](https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#gen
Artem-B wrote:
The description of the flat address space in the `TargetTransformInfo.h` is
somewhat vague and both, soo specific and not precise enough, IMO:
```
The flat address space is a
/// generic address space that can be used access multiple segments of memory
/// with different addre
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/107936
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Artem-B wrote:
It may be worth adding a note about this in the release notes.
https://github.com/llvm/llvm-project/pull/107936
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/107734
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Artem-B closed
https://github.com/llvm/llvm-project/pull/107483
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Artem-B created
https://github.com/llvm/llvm-project/pull/107483
Right now we're bailing out too early, and `-cuid` does not get set for the
host-only compilations.
>From 52a27293d1c93a7ed4dcef845f705808afa3c273 Mon Sep 17 00:00:00 2001
From: Artem Belevich
Date: Thu, 5 Se
https://github.com/Artem-B closed
https://github.com/llvm/llvm-project/pull/99646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Artem-B wrote:
This is very Windows-specific.
@rnk -- would you have time to take a look?
https://github.com/llvm/llvm-project/pull/101350
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
Artem-B wrote:
I can land the patch.
The buildkite failures appear to be unrelated (something in lldb tests).
Let's wait till clang format checks are done.
https://github.com/llvm/llvm-project/pull/99646
___
cfe-commits mailing list
cfe-commits@lists
Artem-B wrote:
Buildkite failures are caused by lldb and are unrelated. We're good to go.
https://github.com/llvm/llvm-project/pull/99646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commit
@@ -0,0 +1,216 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
UTC_ARGS: --default-march nvptx64 --version 5
+; RUN: llc < %s -march=nvptx64 -mcpu=sm_32 | FileCheck %s
--check-prefixes=SM30,CHECK
+; RUN: %if ptxas %{ llc < %s -march=nvptx64 -mcp
https://github.com/Artem-B approved this pull request.
https://github.com/llvm/llvm-project/pull/99646
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -9017,6 +9017,10 @@ def err_global_call_not_config : Error<
def err_ref_bad_target : Error<
"reference to %select{__device__|__global__|__host__|__host__ __device__}0 "
"%select{function|variable}1 %2 in
%select{__device__|__global__|__host__|__host__ __device__}3 funct
@@ -115,20 +143,65 @@ static bool hasAttr(const Decl *D, bool
IgnoreImplicitAttr) {
});
}
+SemaCUDA::CUDATargetContext::CUDATargetContext(SemaCUDA *S,
Artem-B wrote:
This could probably be moved into the header.
https://github.com/llvm/llvm-projec
https://github.com/Artem-B edited
https://github.com/llvm/llvm-project/pull/103031
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/Artem-B commented:
Considering that we're adding another interesting quirk to how we interpret
target attributes & function calls, it would be useful to run this by a
language lawyer to make sure we're not missing something.
@zygoloid - would you have time to take a look or
https://github.com/Artem-B closed
https://github.com/llvm/llvm-project/pull/102969
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 1037 matches
Mail list logo
