https://github.com/Pierre-vh closed
https://github.com/llvm/llvm-project/pull/83558
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -6,32 +6,32 @@
// R600-based processors.
//
-// RUN: %clang -E -dM -target r600 -mcpu=r600 %s 2>&1 | FileCheck
--check-prefixes=ARCH-R600,R600 %s -DCPU=r600
-// RUN: %clang -E -dM -target r600 -mcpu=rv630 %s 2>&1 | FileCheck
--check-prefixes=ARCH-R600,R600 %s -DCPU=r600
-
yxsamliu wrote:
When clang does host compilation, it essentially makes an assumption that the
generated IR for host does not depend on the assumed GPU arch, or, the
generated IR may be affected by assumed GPU arch, but it won't affect the
program output. This is true in most cases. For example
yxsamliu wrote:
in HIP headers, warpSize is defined with __AMDGCN_WAVEFRONT_SIZE and there are
a bunch of uses of __AMDGCN_WAVEFRONT_SIZE or warpSize as constants:
https://github.com/search?q=repo%3AROCm%2Fclr%20__AMDGCN_WAVEFRONT_SIZE&type=code
These can be fixed relatively easily by conditio
yxsamliu wrote:
for example, rocprim assumes warpSize is constant
https://github.com/ROCm/rocPRIM/blob/6325547d514b46d1ab51aff0195851b3fcc626d1/rocprim/include/rocprim/intrinsics/thread.hpp#L54
since device_warp_size() is used as non-type template arguments and these code
are not conditioned f
@@ -4306,10 +4306,10 @@
// Begin amdgcn tests
-// RUN: %clang -mcpu=gfx803 -E -dM %s -o - 2>&1 \
+// RUN: %clang -mcpu=gfx803 -E -dM -Xclang -fcuda-is-device %s -o - 2>&1 \
yxsamliu wrote:
C code compiled with target amdgcn should not depend
@@ -6,32 +6,32 @@
// R600-based processors.
//
-// RUN: %clang -E -dM -target r600 -mcpu=r600 %s 2>&1 | FileCheck
--check-prefixes=ARCH-R600,R600 %s -DCPU=r600
-// RUN: %clang -E -dM -target r600 -mcpu=rv630 %s 2>&1 | FileCheck
--check-prefixes=ARCH-R600,R600 %s -DCPU=r600
-
yxsamliu wrote:
Did you try this patch with internal PSDB? This will likely break all HIP
programs.
This is because HIP is single source program and users usually expect the
common device-side predefined macros is seen in both host and device
compilations. e.g. they could write a kernel using
Pierre-vh wrote:
> This was the original behavior of my patch, but I reverted it because it
> broke all the HIP headers that were unintentionally relying on this. Has that
> been resolved?
Was an issue opened for that? How many headers are affected?
https://github.com/llvm/llvm-project/pull/8
jhuber6 wrote:
This was the original behavior of my patch, but I reverted it because it broke
all the HIP headers that were unintentionally relying on this. Has that been
resolved?
https://github.com/llvm/llvm-project/pull/83558
___
cfe-commits maili
https://github.com/Pierre-vh updated
https://github.com/llvm/llvm-project/pull/83558
>From 3730631ac58425f559f4bc3cfe3da89e6367c1c5 Mon Sep 17 00:00:00 2001
From: pvanhout
Date: Fri, 1 Mar 2024 12:43:55 +0100
Subject: [PATCH 1/2] [clang][AMDGPU] Don't define feature macros on host code
Those m
@@ -292,8 +292,14 @@ void AMDGPUTargetInfo::getTargetDefines(const LangOptions
&Opts,
}
Builder.defineMacro(Twine("__") + Twine(CanonName) + Twine("__"));
+
+ // Don't emit feature macros in host code because in such cases the
+ // feature list is not accurate.
+ if (I
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Pierre van Houtryve (Pierre-vh)
Changes
Those macros are unreliable because our features are mostly uninitialized at
that stage, so any macro we define is unreliable.
Fixes SWDEV-447308
---
Full diff: https://github.com/llvm/llvm-project
https://github.com/Pierre-vh created
https://github.com/llvm/llvm-project/pull/83558
Those macros are unreliable because our features are mostly uninitialized at
that stage, so any macro we define is unreliable.
Fixes SWDEV-447308
>From 3730631ac58425f559f4bc3cfe3da89e6367c1c5 Mon Sep 17 00:0
14 matches
Mail list logo
