https://github.com/jhuber6 approved this pull request.
Seems straightforward enough
https://github.com/llvm/llvm-project/pull/79038
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/79039
___
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/79039
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -99,6 +99,7 @@ class ROCDLDialectLLVMIRTranslationInterface
if (!llvmFunc->hasFnAttribute("amdgpu-flat-work-group-size")) {
llvmFunc->addFnAttr("amdgpu-flat-work-group-size", "1,256");
}
+ llvmFunc->addFnAttr("amdgpu-implicitarg-num-bytes", "256");
-
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/78333
___
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/79231
Summary:
The offloading wrapper is a object file that contains code necessary to
register offloading entries for the given runtime. Currently, we
expected only one of these to be present when we make the final
exe
@@ -0,0 +1,7 @@
+/// Some target-specific options are ignored for GPU, so %clang exits with
code 0.
+// DEFINE: %{gpu_opts} = --cuda-gpu-arch=sm_60
--cuda-path=%S/Inputs/CUDA/usr/local/cuda --no-cuda-version-check
+// DEFINE: %{check} = %clang -### -c %{gpu_opts} -mcmodel=medium
@@ -0,0 +1,7 @@
+/// Some target-specific options are ignored for GPU, so %clang exits with
code 0.
+// DEFINE: %{gpu_opts} = --cuda-gpu-arch=sm_60
--cuda-path=%S/Inputs/CUDA/usr/local/cuda --no-cuda-version-check
+// DEFINE: %{check} = %clang -### -c %{gpu_opts} -mcmodel=medium
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/79222
___
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/79314
Summary:
A relocatable link through `clang -r` can go through the
clang-linker-wrapper if offloading is enabled. This will have the effect
of linking the device code and creating the wrapper module. It will then
b
@@ -0,0 +1,5 @@
+/// Some target-specific options are ignored for GPU, so %clang exits with
code 0.
+// DEFINE: %{check} = %clang -### -c -mcmodel=medium
jhuber6 wrote:
Probably depends on the option we're testing. We could do both.
https://github.com/llvm/llvm
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/79314
>From 0f8d9bb329b6d50493286e117ea0fe45e0a49247 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 24 Jan 2024 09:41:15 -0600
Subject: [PATCH 1/2] [LinkerWrapper] Do not link device code under a
relocatable l
jhuber6 wrote:
> Do we need two different linkages or could the COFF setting be used in both?
> Can we have a test to show the merging works as expected?
Doing a merge intentionally will be difficult until I add another flag to do
this on purpose as an extra feature. This patch just changes it
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/79314
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/79231
___
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/79373
Summary:
We support `--target=nvptx64-nvidia-cuda` as a way to target the NVPTX
architecture from standard CPU. This patch simply uses the existing
support for handling `--offload-arch=native` to also apply to the
jhuber6 wrote:
Maybe need to specify `--target=x86_64-unknown-linux-gnu` in the test?
https://github.com/llvm/llvm-project/pull/79222
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
Some interesting points, I'll try to clarify some things.
> This option may not as well as one would hope.
>
> Problem #1 is that it will drastically slow down compilation for some users.
> NVIDIA GPU drivers are loaded on demand, and the process takes a while
> (O(second), dep
jhuber6 wrote:
> I think I'm with Art on this one.
>
> > > Problem #2 [...] The arch=native will create a working configuration, but
> > > would build more than necessary.
> >
> >
> > It will target the first GPU it finds. We could maybe change the behavior
> > to detect the newest, but the
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/79373
>From 145b7bc932ce3ffa46545cd7af29b1c93981429c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 24 Jan 2024 15:34:00 -0600
Subject: [PATCH 1/2] [NVPTX] Add support for -march=native in standalone NVPTX
Sum
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/79373
>From 145b7bc932ce3ffa46545cd7af29b1c93981429c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 24 Jan 2024 15:34:00 -0600
Subject: [PATCH 1/3] [NVPTX] Add support for -march=native in standalone NVPTX
Sum
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/79373
>From 145b7bc932ce3ffa46545cd7af29b1c93981429c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 24 Jan 2024 15:34:00 -0600
Subject: [PATCH 1/3] [NVPTX] Add support for -march=native in standalone NVPTX
Sum
jhuber6 wrote:
> On the other hand, I'd be OK with providing --offload-arch=native translating
> into "compile for all present GPU variants", with a possibility to further
> adjust the selected set with the usual --no-offload-arch-foo, if the user
> needs to. This will at least produce code th
jhuber6 wrote:
> User confusion is only part of the issue here. With any single GPU choice we
> would still potentially produce a nonworking binary, if our GPU choice does
> not match what the user wants.
>
> "all GPUs" has the advantage of always producing the binary that's guaranteed
> to wo
jhuber6 wrote:
> > I think the semantics of native on other architectures are clear enough
> > here.
>
> I don't think we have the same idea about that. Let's spell it out, so
> there's no confusion.
>
> [GCC
> manual](https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-march-16)
> sa
jhuber6 wrote:
> > This method of compilation is not like CUDA, so we can't target all the
> > GPUs at the same time.
>
> I think this is the key fact I was missing. If the patch is only for a
> standalone compilation which does not do multi-GPU compilation in principle,
> then your approach
jhuber6 wrote:
> > This method of compilation is not like CUDA, so we can't target all the
> > GPUs at the same time.
>
> Can you clarify for me -- what are you compiling where it's impossible to
> target multiple GPUs in the binary? I'm confused because Art is understanding
> that it's not C
jhuber6 wrote:
> I...think I understand.
>
> Is the output of this compilation step a cubin, then?
Yes, it will spit out a simple `cubin` instead of a fatbinary. The NVIDIA
toolchain is much worse about this stuff than the AMD one, but in general it
works. You can check with `-###` or whateve
jhuber6 wrote:
> Got it, okay, thanks.
>
> Since this change only applies to `--target=nvptx64-nvidia-cuda`, fine by me.
> Thanks for putting up with our scrutiny. :)
No problem, I probably should've have been clearer in my commit messages.
https://github.com/llvm/llvm-project/pull/79373
___
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/79373
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 commented:
Thanks, some comments.
https://github.com/llvm/llvm-project/pull/78057
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,62 @@
+//===- OffloadWrapper.h --r-*- C++ -*-===//
+//
+// 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: Apach
@@ -568,32 +590,45 @@ void createRegisterFatbinFunction(Module &M,
GlobalVariable *FatbinDesc,
} // namespace
-Error wrapOpenMPBinaries(Module &M, ArrayRef> Images) {
- GlobalVariable *Desc = createBinDesc(M, Images);
+Error OffloadWrapper::wrapOpenMPBinaries(
+Module &
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/78057
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -568,32 +590,45 @@ void createRegisterFatbinFunction(Module &M,
GlobalVariable *FatbinDesc,
} // namespace
-Error wrapOpenMPBinaries(Module &M, ArrayRef> Images) {
- GlobalVariable *Desc = createBinDesc(M, Images);
+Error OffloadWrapper::wrapOpenMPBinaries(
+Module &
@@ -0,0 +1,62 @@
+//===- OffloadWrapper.h --r-*- C++ -*-===//
+//
+// 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: Apach
@@ -568,32 +590,45 @@ void createRegisterFatbinFunction(Module &M,
GlobalVariable *FatbinDesc,
} // namespace
-Error wrapOpenMPBinaries(Module &M, ArrayRef> Images) {
- GlobalVariable *Desc = createBinDesc(M, Images);
+Error OffloadWrapper::wrapOpenMPBinaries(
+Module &
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/78057
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -568,32 +590,45 @@ void createRegisterFatbinFunction(Module &M,
GlobalVariable *FatbinDesc,
} // namespace
-Error wrapOpenMPBinaries(Module &M, ArrayRef> Images) {
- GlobalVariable *Desc = createBinDesc(M, Images);
+Error OffloadWrapper::wrapOpenMPBinaries(
+Module &
jhuber6 wrote:
LLVM changes look unrelated, it was originally copied from OpenBSD it seems.
But it's not a major issue.
https://github.com/llvm/llvm-project/pull/78061
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi
jhuber6 wrote:
> > LLVM changes look unrelated, it was originally copied from OpenBSD it
> > seems. But it's not a major issue.
>
> FWIW I opened a few PRs in FreeBSD regarding this.
Yeah, go ahead and move that portion there so the people who know more about
LLVM's regex can look at it compa
https://github.com/jhuber6 approved this pull request.
Thanks.
https://github.com/llvm/llvm-project/pull/78061
___
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.
Thanks. I'll probably make a patch after this to make the surface handling for
CUDA default off because it seems to be unsupported.
https://github.com/llvm/llvm-project/pull/78057
___
cfe-commits
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/78061
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -21067,6 +21067,10 @@ Sema::ActOnOpenMPDependClause(const
OMPDependClause::DependDataTy &Data,
ExprTy = ATy->getElementType();
else
ExprTy = BaseType->getPointeeType();
+// bug 69200
+if (ExprTy.isNull()) {
+
jhuber6 wrote:
Thanks for the patch, this one likely fell through the cracks because it has no
assigned reviewers. We'll need a test based off of the original bug report. Put
that in `clang/test/OpenMP/.c` and then look at other tests for what
it should look like. LLVM uses `lit` to test, you
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/78359
Summary:
The linker wrapper's job is to sort various embedded inputs into a list
of files that participate in a single link job. So far, this has been
completely 1-to-1, that is, each input file participates in ex
jhuber6 wrote:
This is a redo of what was originally in
https://github.com/llvm/llvm-project/pull/72442
https://github.com/llvm/llvm-project/pull/78359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
@@ -162,6 +162,19 @@ class OffloadFile : public OwningBinary {
std::unique_ptr Buffer)
: OwningBinary(std::move(Binary), std::move(Buffer)) {}
+ /// Make a deep copy of this offloading file.
+ OffloadFile copy() const {
+std::unique_ptr Buffer = Memor
jhuber6 wrote:
Looks like it still has that Windows failure. That's going to be impossible to
debug on account of the fact that I have no clue how to run this thing on
Windows. The precommit checking takes a whole day to run as well. The only
error message is "invalid argument", so I really ha
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/78359
>From d7c8a6e0cb2289af939a90e82afbc6e35b08010c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 15 Jan 2024 15:42:06 -0600
Subject: [PATCH 1/2] [LinkerWrapper] Handle AMDGPU Target-IDs correctly when
linki
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/78359
>From d7c8a6e0cb2289af939a90e82afbc6e35b08010c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 15 Jan 2024 15:42:06 -0600
Subject: [PATCH 1/3] [LinkerWrapper] Handle AMDGPU Target-IDs correctly when
linki
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/78359
>From 2a460f6ff9e7bca938adca5487609df41616e8c1 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 15 Jan 2024 15:42:06 -0600
Subject: [PATCH] [LinkerWrapper] Handle AMDGPU Target-IDs correctly when
linking
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/76571
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/72442
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
Replaced by https://github.com/llvm/llvm-project/pull/78359
https://github.com/llvm/llvm-project/pull/72442
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/78359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Joseph Huber
Date: 2024-01-18T10:42:13-06:00
New Revision: 2b804f875579995b1588f1a079e265929163d0e4
URL:
https://github.com/llvm/llvm-project/commit/2b804f875579995b1588f1a079e265929163d0e4
DIFF:
https://github.com/llvm/llvm-project/commit/2b804f875579995b1588f1a079e265929163d0e4.diff
Author: Joseph Huber
Date: 2024-01-18T10:56:33-06:00
New Revision: cb2f340850db007aebf5012858697ba5afc1ce4e
URL:
https://github.com/llvm/llvm-project/commit/cb2f340850db007aebf5012858697ba5afc1ce4e
DIFF:
https://github.com/llvm/llvm-project/commit/cb2f340850db007aebf5012858697ba5afc1ce4e.diff
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 849c8dab14c9332081a8c6331c9ca0c234793393 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Jun 2024 15:14:52 -0500
Subject: [PATCH] [Clang] Introduce 'clang-nvlink-wrappaer' to work around
'nvlink'
jhuber6 wrote:
Re-did it and tested it against `libc` in
https://github.com/llvm/llvm-project/pull/96972 so it will have a CI running it
one that lands. it works for other cases I've tested, but let me know if
something else should be added.
https://github.com/llvm/llvm-project/pull/96561
__
https://github.com/jhuber6 approved this pull request.
This is definitely overdue, thanks.
https://github.com/llvm/llvm-project/pull/97028
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-comm
https://github.com/jhuber6 commented:
Could you provide a more descriptive summary?
I thought we discussed that the dynamic support would just use the static
scheduler, but this seems to implement it? I personally don't want to see more
things in the OpenMP runtime relying on `malloc` if we ca
jhuber6 wrote:
> Malloc cannot be helped here if we want to have correctness. Currently it is
> just broken and not even runnable.
I figured that all this code would go away if we just made all schedules static.
https://github.com/llvm/llvm-project/pull/97065
__
https://github.com/jhuber6 approved this pull request.
Seems reasonable as I believe there were extra uses that needed the size.
https://github.com/llvm/llvm-project/pull/97082
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.
@@ -942,6 +942,36 @@ struct Amdgpu final : public VariadicABIInfo {
}
};
+struct NVPTX final : public VariadicABIInfo {
+
+ bool enableForTarget() override { return true; }
+
+ bool vaListPassedInSSARegister() override { return true; }
+
+ Type *vaListType(LLVMContext &Ct
jhuber6 wrote:
> The nvptx lowering looks dubious - values smaller than slot size should be
> passed with the same alignment as the slot and presently aren't. A struct
> containing i8, i16 or half should be miscompiled on nvptx as written.
I mentioned this in the original patch, it's correct a
jhuber6 wrote:
> Patch should not land. Need to know what bug this was trying to address to
> guess at what the right fix would be.
My understanding was that the variadics did lowering to a struct with a minimum
alignment of four. This currently *doesn't* do that, hence my confusion. The
curr
jhuber6 wrote:
> > You could theoretically break this if you didn't go through the C ABI and
> > ignored type promotion, but I'm not concerned with that kind of misuse
> > since it's against the ABI in the first place.
>
> The IR has its own ABI that may or may not match whatever the platform
@@ -942,6 +942,36 @@ struct Amdgpu final : public VariadicABIInfo {
}
};
+struct NVPTX final : public VariadicABIInfo {
+
+ bool enableForTarget() override { return true; }
+
+ bool vaListPassedInSSARegister() override { return true; }
+
+ Type *vaListType(LLVMContext &Ct
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/96370
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
Lower than native alignment is legal in AMDGPU hardware and it's possible to
work around in the `printf` implementation, closing.
https://github.com/llvm/llvm-project/pull/96370
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ht
@@ -54,7 +54,34 @@ class MockArgList {
}
template LIBC_INLINE T next_var() {
-++arg_counter;
+arg_counter++;
+return T(arg_counter);
+ }
+
+ size_t read_count() const { return arg_counter; }
+};
+
+// Used by the GPU implementation to parse how many bytes ne
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 12d00a54169fef15efccfe9472db25b1261d31d3 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Jun 2024 15:14:52 -0500
Subject: [PATCH] [Clang] Introduce 'clang-nvlink-wrappaer' to work around
'nvlink'
@@ -116,8 +116,7 @@ class LLVM_LIBRARY_VISIBILITY NVPTXTargetInfo : public
TargetInfo {
}
BuiltinVaListKind getBuiltinVaListKind() const override {
-// FIXME: implement
-return TargetInfo::CharPtrBuiltinVaList;
+return TargetInfo::VoidPtrBuiltinVaList;
---
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 1/2] [NVPTX] Implement variadic functions using IR lowering
Summar
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 3b10fce6b3d3f8eeb7bd9a3828d488362bb061dd Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Jun 2024 15:14:52 -0500
Subject: [PATCH] [Clang] Introduce 'clang-nvlink-wrappaer' to work around
'nvlink'
jhuber6 wrote:
This patch causes the `offloading/bug51781.c` test to fail when compiled with
reductions + debug information.
```console
> clang ../offload/test/offloading/bug51781.c -fopenmp -O1 --offload-arch=sm_89
> -DADD_REDUCTION --offload-device-only -gline-tables-only
!dbg attachment poin
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 2bb5bd081a29b9bf1c4e6e0f727e21a1b9258920 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Jun 2024 15:14:52 -0500
Subject: [PATCH] [Clang] Introduce 'clang-nvlink-wrappaer' to work around
'nvlink'
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 2d3957ac14906d569acf5b3ceb5c7e2f4dfabe54 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Jun 2024 15:14:52 -0500
Subject: [PATCH] [Clang] Introduce 'clang-nvlink-wrappaer' to work around
'nvlink'
jhuber6 wrote:
Would it be possible for you to investigate that? It really shouldn't be
required if we can't help it.
https://github.com/llvm/llvm-project/pull/96742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bi
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/97573
Summary:
The linker wrapper's job is to extract embedded device code from fat
binaries and create linked images that can then be embedded and
executed. In order to support LTO, we originally reinvented all of the
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/97495
___
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/97663
Summary:
The parsing for this was implemented, but we never hooked up the default
value to the result of this clause. This patch adds the support by
making it default to the requires directive.
>From fa3561bd4d4
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
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
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 equivale
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
@@ -673,8 +673,12 @@ std::unique_ptr AllocateTarget(const
llvm::Triple &Triple,
}
case llvm::Triple::spirv64: {
if (os != llvm::Triple::UnknownOS ||
-Triple.getEnvironment() != llvm::Triple::UnknownEnvironment)
+Triple.getEnvironment() != llvm::Triple::
@@ -54,3 +56,77 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions
&Opts,
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
&Opts,
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
DefineStd(Builder, "SPIRV64", Opts);
}
+
+namespace {
+const AMDGPUTargetInfo AMDGPUTI(llvm::Triple("amdgcn-amd-amdhsa"), {});
+
+} //
@@ -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" &&
+getTarget().getTr
@@ -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" &&
+getTarget().getTr
@@ -309,7 +309,45 @@ StringRef AMDGPU::getCanonicalArchName(const Triple &T,
StringRef Arch) {
void AMDGPU::fillAMDGPUFeatureMap(StringRef GPU, const Triple &T,
StringMap &Features) {
// XXX - What does the member GPU mean if device name str
@@ -309,7 +309,45 @@ StringRef AMDGPU::getCanonicalArchName(const Triple &T,
StringRef Arch) {
void AMDGPU::fillAMDGPUFeatureMap(StringRef GPU, const Triple &T,
StringMap &Features) {
// XXX - What does the member GPU mean if device name str
@@ -54,3 +56,76 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions
&Opts,
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
DefineStd(Builder, "SPIRV64", Opts);
}
+
+static const AMDGPUTargetInfo AMDGPUTI(llvm::Triple("amdgcn-amd-amdhsa"), {});
+
+ArrayRef S
@@ -54,3 +56,76 @@ void SPIRV64TargetInfo::getTargetDefines(const LangOptions
&Opts,
BaseSPIRVTargetInfo::getTargetDefines(Opts, Builder);
DefineStd(Builder, "SPIRV64", Opts);
}
+
+static const AMDGPUTargetInfo AMDGPUTI(llvm::Triple("amdgcn-amd-amdhsa"), {});
+
+ArrayRef S
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
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
@@ -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
801 - 900 of 1001 matches
Mail list logo
