jhuber6 wrote:
> @jhuber6 The clang format errors are mostly due to my local version of
> `clang-format` disagreeing with the buildbot's version. Its a bit annoying,
> but it shouldn't be too much of a problem given I plan on squashing and
> merging once this gets approved.
>
> I added new
https://github.com/jhuber6 commented:
Seems to be lots of accidental `clang-format` changes. Why do we need new flags
for this instead of just using the old ones and changing behavior when the
target is a known GPU? I.e. SPIR-V, CUDA, or HSA.
https://github.com/llvm/llvm-project/pull/94268
jhuber6 wrote:
> Incrementing by align is just a bug, of course the size is the real value.
> Whether we want to continue wasting space is another not-correctness
> discussion
Struct padding is pretty universal, AMDGPU seems the odd one out here. I
wouldn't mind it so much if it didn't
jhuber6 wrote:
> > Here, because the minimum alignment is 4, we will only increment the
> > buffer by 4,
>
> It should be incrementing by the size? 4 byte aligned access of 8 byte type
> should work fine
Guess that's an AMD thing, so I'm going to assume that @JonChesterfield wrote
this
https://github.com/jhuber6 approved this pull request.
Out of curiosity, how badly does this fail when you use `--offload-new-driver`
w/ HIP? I swear I'll get that passing the internal test suite eventually,
there's a single case for emitting IR that comgr uses that I can't seem to fix.
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/96370
Summary:
The variadics lowering for AMDGPU puts all the arguments into a void
pointer struct. The current logic dictates that the minimum alignment is
four regardless of what the underlying type is. This is
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/96369
Summary:
This patch implements the `printf` family of functions on the GPU using
the new variadic support. This patch adapts the old handling in the
`rpc_fprintf` placeholder, but adds an extra RPC call to get
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96015
>From 8bd49caa9fa93fd3d0812e0a4315f8ff4956056a Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 17 Jun 2024 15:32:31 -0500
Subject: [PATCH] [NVPTX] Implement variadic functions using IR lowering
Summary:
jhuber6 wrote:
Here's a radical question, do we really want to use CMake's support for this? I
remember a discussion recently about the increasingly large amount of time
spent in the CMake configuration step, and most of that time is spent during
these flag checks which pretty much all
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96015
>From 0cae8db24812b2ab5539cc581fbc461af072b5fd Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 17 Jun 2024 15:32:31 -0500
Subject: [PATCH] [NVPTX] Implement variadic functions using IR lowering
Summary:
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96015
>From a05b24a06429c1ad6c4988f232442d53010e79a9 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 17 Jun 2024 15:32:31 -0500
Subject: [PATCH] [NVPTX] Implement variadic functions using IR lowering
Summary:
jhuber6 wrote:
> With the possible exception of some alignment handling this looks about as
> I'd expect it to. Ideally we'd get some feedback from nvptx-associated people
> but fixing libc is a good sign
Yep, I believe @Artem-B is on vacation, so hopefully @AlexMaclean can chime in.
This
@@ -938,6 +938,37 @@ struct Amdgpu final : public VariadicABIInfo {
}
};
+struct NVPTX final : public VariadicABIInfo {
+
+ bool enableForTarget() override { return true; }
+
+ bool vaListPassedInSSARegister() override { return true; }
+
+ Type *vaListType(LLVMContext )
@@ -17,6 +17,8 @@
#define MODULE_PASS(NAME, CREATE_PASS)
#endif
MODULE_PASS("generic-to-nvvm", GenericToNVVMPass())
+MODULE_PASS("expand-variadics",
jhuber6 wrote:
Couldn't remember if adding it to `addIRPasses` applied to all uses. I remember
something like
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96015
>From bf6f8852621f4a5ac58e6d062d7c78e5eb639c1a Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 17 Jun 2024 15:32:31 -0500
Subject: [PATCH] [NVPTX] Implement variadic functions using IR lowering
Summary:
@@ -203,8 +203,15 @@ ABIArgInfo NVPTXABIInfo::classifyArgumentType(QualType Ty)
const {
void NVPTXABIInfo::computeInfo(CGFunctionInfo ) const {
if (!getCXXABI().classifyReturnType(FI))
FI.getReturnInfo() = classifyReturnType(FI.getReturnType());
- for (auto :
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/96015
Summary:
This patch implements support for variadic functions for NVPTX targets.
The implementation here mainly follows what was done to implement it for
AMDGPU in https://github.com/llvm/llvm-project/pull/93362.
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/95061
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 approved this pull request.
LG overall, the growing number of "Is gpu target and some vendor" in the Driver
is concerning.
https://github.com/llvm/llvm-project/pull/95061
___
cfe-commits mailing list
@@ -907,7 +907,8 @@ void CodeGenModule::Release() {
if (Context.getTargetInfo().getTriple().isWasm())
EmitMainVoidAlias();
- if (getTriple().isAMDGPU()) {
+ if (getTriple().isAMDGPU() ||
+ (getTriple().isSPIRV() && getTriple().getVendor() == llvm::Triple::AMD))
jhuber6 wrote:
If you really need this, perhaps you can check if the Triple will invoke the
fallback toolchain or something? Would be a lack of vendor in the Triple.
https://github.com/llvm/llvm-project/pull/95763
___
cfe-commits mailing list
jhuber6 wrote:
> > I thought that clang accepted `-rpath `? I see that format when I try
> > CPU offloading.
>
> Yeah, but when running `--target=x86_64` and underlying gcc command is issued
> and complains about `-rpath `
Oh, I see. When using `-fopenmp-targets=x86_64` it goes through the
jhuber6 wrote:
I remember intentionally using the clang argument format instead of
`-Wl,-rpath,` because the `-Wl` format would try to forward it to things
like `nvlink` which don't support it.
https://github.com/llvm/llvm-project/pull/95763
___
jhuber6 wrote:
The tests use an option that causes nothing to actually run, so it only uses
the filename.
https://github.com/llvm/llvm-project/pull/95763
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
jhuber6 wrote:
What is this?
https://github.com/llvm/llvm-project/pull/95763
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 commented:
I thought that clang accepted `-rpath `? I see that format when I try CPU
offloading.
https://github.com/llvm/llvm-project/pull/95763
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/95763
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -128,12 +128,13 @@ enum class CudaArch {
GFX12_GENERIC,
GFX1200,
GFX1201,
+ AMDGCNSPIRV,
Generic, // A processor model named 'generic' if the target backend defines a
// public one.
LAST,
CudaDefault = CudaArch::SM_52,
- HIPDefault =
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/95061
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -128,12 +128,13 @@ enum class CudaArch {
GFX12_GENERIC,
GFX1200,
GFX1201,
+ AMDGCNSPIRV,
Generic, // A processor model named 'generic' if the target backend defines a
// public one.
LAST,
CudaDefault = CudaArch::SM_52,
- HIPDefault =
jhuber6 wrote:
> Ooh... I think I know exactly what may be causing this.
I've observed this a few times. For my case it's usually when some application
hangs on the GPU and no one notices, then these tools hang forever and it takes
awhile to notice. Figured an error is friendlier since I
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/94765
___
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/94765
Summary:
AMDGPU supports a `target-id` feature which is used to qualify targets
with different incompatible features. These are both rules and target
features. Currently, we pass `-target-cpu` twice when
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/94751
___
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/94751
>From 0e367c72a1cc163fd781f98b9fac809d90f4beb7 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 7 Jun 2024 08:15:06 -0500
Subject: [PATCH] [Clang] Add timeout for GPU detection utilities
Summary:
The
jhuber6 wrote:
No active test because I have no clue how you would, but I intentionally made
it time out and it returns a 'Child timed out` error as expected.
https://github.com/llvm/llvm-project/pull/94751
___
cfe-commits mailing list
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/94751
Summary:
The utilities `nvptx-arch` and `amdgpu-arch` are used to support
`--offload-arch=native` among other utilities in clang. However, these
rely on the GPU drivers to query the features. In certain cases
@@ -8,10 +8,15 @@ add_custom_target(libc-long-running-tests)
add_subdirectory(UnitTest)
-if(LIBC_TARGET_OS_IS_GPU AND
jhuber6 wrote:
Done
https://github.com/llvm/llvm-project/pull/93362
___
cfe-commits mailing
jhuber6 wrote:
> Early exit on lack of va_start will be incorrect in the lowering case, which
> is the only one enabled by default. I believe existing comments are all
> addressed.
Figured if there's no `va_start` there's nothing for the pass to do anyway.
> Precommit the cmake diagnostic
@@ -8,10 +8,15 @@ add_custom_target(libc-long-running-tests)
add_subdirectory(UnitTest)
-if(LIBC_TARGET_OS_IS_GPU AND
jhuber6 wrote:
Can we precommit or move this to a separate patch
https://github.com/llvm/llvm-project/pull/93362
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/93362
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 commented:
Overall I think this is good. Address the existing comments and I think we
should be able to land it. Potentially we should be able to check for the
existence of `va_start` in the module to early-exit like you said, which will
keep functional changes to a
jhuber6 wrote:
> An offline suggestion from Pierre is that this should early-exit if there are
> no variadic functions in the module. That's a good thing, I'd like to
> consider it another of the increase-complexity-for-decreased-compile-time to
> implement after something has landed.
I
jhuber6 wrote:
I can confirm that it passes the tests against the `libc` targets, namely basic
`stdarg.h` implementations and `sprintf`.
https://github.com/llvm/llvm-project/pull/93362
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/jhuber6 approved this pull request.
I've wondered about these as well, there might also be some OpenMP tests that
have `requries powerpc-registered-target` or similar that could be removed. I
guess we'll see what the CI thinks with this patch.
jhuber6 wrote:
ping
https://github.com/llvm/llvm-project/pull/91264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/93599
___
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/84420
>From b0dc390bc52059d7a31b5f0878ffb8024201774d Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 7 Mar 2024 15:48:00 -0600
Subject: [PATCH] [Offload] Move HIP and CUDA to new driver by default
Summary:
jhuber6 wrote:
> > > If `-march` is the wrong option then let's start deprecating it and
> > > remove it altogether in the next llvm release. But, as long as it is
> > > here, it should be equivalent to `--offload-arch`.
> >
> >
> > Honestly not a bad idea. I could make a patch warning users
jhuber6 wrote:
> If `-march` is the wrong option then let's start deprecating it and remove it
> altogether in the next llvm release. But, as long as it is here, it should be
> equivalent to `--offload-arch`.
Honestly not a bad idea. I could make a patch warning users to use
`--offload-arch`
jhuber6 wrote:
> > I don't think we want to support this. `-march` was the wrong option to use
> > in the first place, and upstream LLVM never supported specifying multiple
> > device images with `-march` so there isn't a legacy argument in trunk.
> > However, AOMP did support this and if
jhuber6 wrote:
I don't think we want to support this. `-march` was the wrong option to use in
the first place, and upstream LLVM never supported specifying multiple device
images with `-march` so there isn't a legacy argument in trunk. However, AOMP
did support this and if it's deemed too
Author: Joseph Huber
Date: 2024-05-14T18:43:42-05:00
New Revision: c5cd049566a795ba5de88dfbb2eb563cad4a9d8a
URL:
https://github.com/llvm/llvm-project/commit/c5cd049566a795ba5de88dfbb2eb563cad4a9d8a
DIFF:
https://github.com/llvm/llvm-project/commit/c5cd049566a795ba5de88dfbb2eb563cad4a9d8a.diff
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/91984
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> would it be more useful to allow swapping the output by environment variable
> and MD5 hash, e.g.
>
> CLANG_LINK_WRAPPER_SWAP_OUTPUT=hash1:file1,hash2:file2
>
> it calculates the MD5 hash of the output file, if matching, swap it with the
> specified file. This way, we can
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/91984
>From 4c60b32a4c1916a3ba575d4edc6d79f9b194ab03 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 13 May 2024 10:53:55 -0500
Subject: [PATCH] [LinkerWrapper] Add an overriding option for debugging
Summary:
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/91984
Summary:
One of the downsides of the linker wrapper is that it made debugging
more difficult. It is very powerful in that it can resolve a lot of
input matching and library handling that could not be done before.
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/91264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/91637
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
I hacked around it in the runtime itself. Obviously this is very OpenMP
specific behavior but so was the old method. Passes all tests now.
https://github.com/llvm/llvm-project/pull/91264
___
cfe-commits mailing list
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/91264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 commented:
There's some code in the `clang-linker-wrapper` that creates the offloadbundler
format for HIP offloading. I think it and the tests use `hipv4` which we could
presumably remove now?
https://github.com/llvm/llvm-project/pull/91637
Author: Joseph Huber
Date: 2024-05-09T09:38:22-05:00
New Revision: fa9e90f5d23312587b3a17920941334e0d1a58a1
URL:
https://github.com/llvm/llvm-project/commit/fa9e90f5d23312587b3a17920941334e0d1a58a1
DIFF:
https://github.com/llvm/llvm-project/commit/fa9e90f5d23312587b3a17920941334e0d1a58a1.diff
Author: Joseph Huber
Date: 2024-05-09T07:05:23-05:00
New Revision: e5e66073c3d404f4dedf1b0be160b7815ccf8903
URL:
https://github.com/llvm/llvm-project/commit/e5e66073c3d404f4dedf1b0be160b7815ccf8903
DIFF:
https://github.com/llvm/llvm-project/commit/e5e66073c3d404f4dedf1b0be160b7815ccf8903.diff
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/87009
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/91516
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> Hmm, hard to tell, need to debug it.
Somehow when I print it in the runtime it shows up as garbage, but the actual
region seems to get correct values. There shouldn't be anything in-between the
arguments I'm printing and the kernel launch however so I'm stumped.
jhuber6 wrote:
I'm getting the same kind of output on `main`, but the warning is mysteriously
absent.
https://github.com/llvm/llvm-project/pull/91264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
jhuber6 wrote:
>
> Maybe. The message is emitted on the host, so there is something wrong with
> the host code or runtime library.
This might be some issue with the host codegen actually.
```console
> clang malloc.c -fopenmp -fopenmp-targets=x86_64-pc-linux-gnu
>
https://github.com/jhuber6 approved this pull request.
Hopefully in the future we can handle this in the linker better.
https://github.com/llvm/llvm-project/pull/85672
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
jhuber6 wrote:
> > > > ```llvm
> > > > struct.anon
> > > > ```
> > >
> > >
> > > Can you provide full IR dump here?
> >
> >
> > https://godbolt.org/z/48h5s3W6v
>
> It does not look like the issue of the target code, I don't see any wrong
> access for __context. Мост probably something
jhuber6 wrote:
> > ```llvm
> > struct.anon
> > ```
>
> Can you provide full IR dump here?
https://godbolt.org/z/48h5s3W6v
https://github.com/llvm/llvm-project/pull/91264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/87009
>From 6dfa6dc2956ca714e98bf24b176315da42446553 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 28 Mar 2024 16:18:19 -0500
Subject: [PATCH] [Libomptarget] Statically link all plugin runtimes
Summary:
This
jhuber6 wrote:
> > ```llvm
> > = load i32, ptr %.capture_expr., align 4
> > ```
>
> Why do you think it reads beyond __context? %2 = getelementptr inbounds
> %struct.anon, ptr %1, i32 0, i32 0 points to the first element in the
> __context, if I'm not missing something. If it has the wrong
jhuber6 wrote:
> I did not build upstream but looking at downstream, I think for some reason
> they don't show up as duplicate symbols. But looking at the code, they should
> be removed. There are uses of those variables in the plugin, so there should
> be only 1 definition.
Does this apply
jhuber6 wrote:
> There are duplicate definitions of the following
>
> ```
> bool llvm::omp::target::ompt::Initialized = false;
>
> ompt_get_callback_t llvm::omp::target::ompt::lookupCallbackByCode = nullptr;
> ompt_function_lookup_t llvm::omp::target::ompt::lookupCallbackByName =
> nullptr;
>
jhuber6 wrote:
I'm unsure how to resolve the issue of `CGF.EmitScalarExpr(NumTeams)` not
returning the correct value now. For the following code
```c
#include
#include
int main() {
int Teams = 10;
#pragma omp target teams distribute parallel for num_teams(Teams)
for (int i = 0; i < 1;
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/90994
___
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/90994
Summary:
Previous patches added support for the LLVM rounding intrinsic
functions. This patch allows them to me emitted using the clang builtins
when targeting AMDGPU.
>From
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/87009
>From 3ea2ae0f5c438b38d0480cfb38a72d2f7a60142c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 28 Mar 2024 16:18:19 -0500
Subject: [PATCH] [Libomptarget] Statically link all plugin runtimes
Summary:
This
jhuber6 wrote:
Going to land this soon.
@jplehr @estewart08 @ronlieb Applied this on the AMD fork, here the diff.
https://gist.github.com/jhuber6/e856fbe9c73acea13b6d30b20605c73e
https://github.com/llvm/llvm-project/pull/87009
___
cfe-commits
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/87009
>From 8c4b7ffb49c8f91768af3bec00669bac5433ec0f Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 28 Mar 2024 16:18:19 -0500
Subject: [PATCH] [Libomptarget] Statically link all plugin runtimes
Summary:
This
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/87009
>From 473a4b9bad09bd9af8186932984be7696711692e Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 28 Mar 2024 16:18:19 -0500
Subject: [PATCH] [Libomptarget] Statically link all plugin runtimes
Summary:
This
jhuber6 wrote:
> > Currently if a user doesn't supply the new "-link-builtin-bitcodes-postopt"
> > option, linking builtin bitcodes happens first, then the optimization
> > pipeline follows. Does that cover the case you're talking about?
>
> I'm thinking of an option that developers can use.
@@ -3476,3 +3472,9 @@ void *AMDGPUDeviceTy::allocate(size_t Size, void *,
TargetAllocTy Kind) {
} // namespace target
} // namespace omp
} // namespace llvm
+
+extern "C" {
+llvm::omp::target::plugin::GenericPluginTy *createPlugin_amdgpu() {
jhuber6 wrote:
I
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/87009
>From 4fd1510c2013fd975ac2ad94b3d201bcd5a9d029 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 28 Mar 2024 16:18:19 -0500
Subject: [PATCH] [Libomptarget] Statically link all plugin runtimes
Summary:
This
https://github.com/jhuber6 approved this pull request.
LG
https://github.com/llvm/llvm-project/pull/89796
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -54,3 +56,76 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions
,
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
DefineStd(Builder, "SPIRV64", Opts);
}
+
+static const AMDGPUTargetInfo AMDGPUTI(llvm::Triple("amdgcn-amd-amdhsa"), {});
+
+ArrayRef
@@ -54,3 +56,76 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions
,
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
DefineStd(Builder, "SPIRV64", Opts);
}
+
+static const AMDGPUTargetInfo AMDGPUTI(llvm::Triple("amdgcn-amd-amdhsa"), {});
+
+ArrayRef
@@ -309,7 +309,45 @@ StringRef AMDGPU::getCanonicalArchName(const Triple ,
StringRef Arch) {
void AMDGPU::fillAMDGPUFeatureMap(StringRef GPU, const Triple ,
StringMap ) {
// XXX - What does the member GPU mean if device name string passed
@@ -309,7 +309,45 @@ StringRef AMDGPU::getCanonicalArchName(const Triple ,
StringRef Arch) {
void AMDGPU::fillAMDGPUFeatureMap(StringRef GPU, const Triple ,
StringMap ) {
// XXX - What does the member GPU mean if device name string passed
@@ -6088,6 +6088,9 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
StringRef Prefix =
llvm::Triple::getArchTypePrefix(getTarget().getTriple().getArch());
if (!Prefix.empty()) {
+if (Prefix == "spv" &&
+
@@ -6088,6 +6088,9 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
StringRef Prefix =
llvm::Triple::getArchTypePrefix(getTarget().getTriple().getArch());
if (!Prefix.empty()) {
+if (Prefix == "spv" &&
+
@@ -54,3 +56,77 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions
,
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
DefineStd(Builder, "SPIRV64", Opts);
}
+
+namespace {
+const AMDGPUTargetInfo AMDGPUTI(llvm::Triple("amdgcn-amd-amdhsa"), {});
+
+} //
@@ -54,3 +56,77 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions
,
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
DefineStd(Builder, "SPIRV64", Opts);
}
+
+namespace {
+const AMDGPUTargetInfo AMDGPUTI(llvm::Triple("amdgcn-amd-amdhsa"), {});
+
+} //
@@ -673,8 +673,12 @@ std::unique_ptr AllocateTarget(const
llvm::Triple ,
}
case llvm::Triple::spirv64: {
if (os != llvm::Triple::UnknownOS ||
-Triple.getEnvironment() != llvm::Triple::UnknownEnvironment)
+Triple.getEnvironment() !=
Author: Joseph Huber
Date: 2024-04-28T06:36:09-05:00
New Revision: bfd269d0d0d6cb58235a838eb659eef97e4f2ebf
URL:
https://github.com/llvm/llvm-project/commit/bfd269d0d0d6cb58235a838eb659eef97e4f2ebf
DIFF:
https://github.com/llvm/llvm-project/commit/bfd269d0d0d6cb58235a838eb659eef97e4f2ebf.diff
jhuber6 wrote:
> I disagree, `--gcc-install-dir` is sure an improvement over
> `--gcc-toolchain`, but they're both weaker than the compile time option
> `GCC_INSTALL_PREFIX` because of runtimes.
>
> You're looking to remove `GCC_INSTALL_PREFIX`, then give a clear alternative
> that's
Author: Joseph Huber
Date: 2024-04-24T07:03:51-05:00
New Revision: eaa2eac8ec73a0473655f2da73f347906d14b00f
URL:
https://github.com/llvm/llvm-project/commit/eaa2eac8ec73a0473655f2da73f347906d14b00f
DIFF:
https://github.com/llvm/llvm-project/commit/eaa2eac8ec73a0473655f2da73f347906d14b00f.diff
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/89803
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
1 - 100 of 1296 matches
Mail list logo
