@@ -54,7 +54,8 @@ class MockArgList {
}
template LIBC_INLINE T next_var() {
-++arg_counter;
+arg_counter =
jhuber6 wrote:
Done
https://github.com/llvm/llvm-project/pull/96369
___
cfe-commits mailing
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/96650
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -54,7 +54,8 @@ class MockArgList {
}
template LIBC_INLINE T next_var() {
-++arg_counter;
+arg_counter =
jhuber6 wrote:
I didn't see any tests that actively depended on this value, and figured that
it does a similar job stating how many bytes
@@ -0,0 +1,73 @@
+//===--- GPU helper functions for printf using RPC
===//
+//
+// 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:
@@ -54,7 +54,8 @@ class MockArgList {
}
template LIBC_INLINE T next_var() {
-++arg_counter;
+arg_counter =
jhuber6 wrote:
I now use the `MockArgList` to tell determine how big the "struct" needs to be
to contain the arguments.
jhuber6 wrote:
> I looked at this and it doesn't look super appealing (turned into something
> of a rabbit hole), it'd duplicate a lot of the existing toolchain, and would
> also try to squat in an already overcrowded space (there's already HIPSPV).
We already have a SPIR-V toolchain for HIP?
jhuber6 wrote:
Also, I just merged the prerequisite patches into this, to get the relevant
changed just look at the most recent commit. The lack of stacked PRs in GitHub
really irks me.
https://github.com/llvm/llvm-project/pull/96369
___
cfe-commits
jhuber6 wrote:
> Do we want some sort of optimization for constant printf? 99% of the time, we
> could parse the string at compile-time. (This sort of optimization is common
> for embedded targets.)
I was going to make a follow-up patch that simply skipped sending back the size
if there were
jhuber6 wrote:
> > I'll need to play with this with my driver code. I'm guessing it's because
> > it needs to generate an entirely separate toolchain? The OpenMP path
> > basically does that by inferring the toolchain from the string value, so we
> > can support `--offload-arch=sm_89,gfx90a`
@@ -284,3 +284,48 @@ Example Usage
Base* basePtr =
basePtr->virtualFunction(); // Allowed since obj is constructed in
device code
}
+
+SPIR-V Support on HIPAMD ToolChain
+==
+
+The HIPAMD ToolChain supports targetting
+`AMDGCN
https://github.com/jhuber6 approved this pull request.
LGTM
https://github.com/llvm/llvm-project/pull/96657
___
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/96657
___
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/96650
Summary:
The StringError class has a specialized method that creates the
inconvertible error code for you. It's much easier to read this way.
>From 6860d0101f8babac086156087854e8f94e4f233e Mon Sep 17 00:00:00
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 859f6a7fce9503275ad7eb39512dc5833a11bb07 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
jhuber6 wrote:
@MaskRay So, I think my symbol resolution is (unsurprisingly) subtly broken. Is
there a canonical way to handle this? I first thought that we could simply
perform the symbol resolutions as normal for every file, but keep track of
which symbols were "lazy". However, I couldn't
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 6c70e542bbb355160b833ede6f86be0366953b88 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
jhuber6 wrote:
> > Hm, that's what I'm doing in the `printf` implementation and it doesn't
> > work without that patch. When I look at the varargs struct it didn't have
> > any padding, which explained why `alignTo(ptr + size, align)` was wrong.
> > So, I was trying to do the following,
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
jhuber6 wrote:
> @Artem-B asked me to review nvptx patches while he's OOO, but this one is
> pretty far outside my depth. Are you OK waiting until he's back? I don't know
> exactly when that will be, but based on his IMs to me, he should be back
> early July.
No problem, I knew that it would
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 5edeeb9816fa5909f27a781f6e7213dd02ccdfa0 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
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 8a52becd358abb2c96ca150db501d58c40b5250b 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
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/96561
___
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/96561
Summary:
The `clang-nvlink-wrapper` is a utility that I removed awhile back
during the transition to the new driver. This patch adds back in a new,
upgraded version that does LTO + archive linking. It's not an
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;
201 - 300 of 1519 matches
Mail list logo
