https://github.com/jhuber6 approved this pull request.
LG
https://github.com/llvm/llvm-project/pull/70401
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
Small change that affects a lot of tests. LG once these are fixed:
```
MLIR :: Target/LLVMIR/omptarget-region-device-llvm.mlir
MLIR :: Target/LLVMIR/omptarget-byref-bycopy-generation-device.mlir
MLIR :: Target/LLVMIR/omptarget-declare-target-llvm-device.mlir
```
jhuber6 wrote:
> Is there some reason stack protectors don't make sense on GPU targets? Or is
> the issue just that the GPU targets in question don't have the necessary
> runtime support?
It's more of the latter as GPUs don't really have much of a runtime. That's why
I didn't want to
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/70799
___
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/70799
>From c791e527ee388659b35707816c0a67bee66dd0da Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 31 Oct 2023 08:12:01 -0500
Subject: [PATCH] [StackProtector] Do not emit the stack protector on GPU
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/70799
Summary:
This patch changes the code generation to not emit the stack protector
metadata on unsupported architectures. The issue was caused by system
toolchains emitting stack protector option by default which
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/70760
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> > This is not being handled for AMDGPU Targets.
>
> I'm assuming this is an artifact of passing all arguments both the host
> target and the offload target? @jhuber6 what's the correct way of filtering
> out irrelevant codegen options?
I don't know what the desired behavior
https://github.com/jhuber6 approved this pull request.
Lots of churn but looks straightforward enough. Few nits.
https://github.com/llvm/llvm-project/pull/70383
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/70383
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -339,9 +339,33 @@ Error GenericKernelTy::init(GenericDeviceTy ,
ImagePtr =
- PreferredNumThreads = GenericDevice.getDefaultNumThreads();
+ // Retrieve kernel environment object for the kernel.
+ GlobalTy KernelEnv(std::string(Name) + "_kernel_environment",
+
@@ -4078,8 +4092,20 @@ OpenMPIRBuilder::createTargetInit(const
LocationDescription , bool IsSPMD) {
Constant *DebugIndentionLevelVal = ConstantInt::getSigned(Int16, 0);
Function *Kernel = Builder.GetInsertBlock()->getParent();
- auto [MinThreadsVal, MaxThreadsVal] =
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/70462
___
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/70462
Summary:
The 'ockl' bitcode library from the ROCm device library contains several
implementations of functions like `printf` and `malloc`. We currently do
not depend on these in the OpenMP toolchain, so we
https://github.com/jhuber6 approved this pull request.
Looks reasonable, the same approach we've always done for these things.
https://github.com/llvm/llvm-project/pull/70369
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -0,0 +1,31 @@
+/*=== type_traits - CUDA wrapper for -===
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/70247
___
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.
Seems fine overall
https://github.com/llvm/llvm-project/pull/70247
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4227,8 +4227,106 @@ static const omp::GV (Function *Kernel) {
llvm_unreachable("No grid value available for this architecture!");
}
+static MDNode *getNVPTXMDNode(Function , StringRef Name) {
+ Module = *Kernel.getParent();
+ NamedMDNode *MD =
@@ -9,6 +9,7 @@
#include "ABIInfoImpl.h"
#include "TargetInfo.h"
#include "llvm/IR/IntrinsicsNVPTX.h"
+#include
jhuber6 wrote:
Is this necessary?
https://github.com/llvm/llvm-project/pull/70247
___
cfe-commits
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/67869
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
Invalidated by a merged PR.
https://github.com/llvm/llvm-project/pull/67869
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Joseph Huber
Date: 2023-10-25T10:42:34-05:00
New Revision: 9bdeab1e7b25240d9282dbdc3617aaade195d62e
URL:
https://github.com/llvm/llvm-project/commit/9bdeab1e7b25240d9282dbdc3617aaade195d62e
DIFF:
https://github.com/llvm/llvm-project/commit/9bdeab1e7b25240d9282dbdc3617aaade195d62e.diff
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/70116
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> Maybe a clang documentation can be added for this generic offloading
> toolchain for OpenMP/CUDA/HIP. Could be a brief description about the
> offloading entries and registration mechanism in the beginning then buffy it
> up later.
We have
https://github.com/jhuber6 approved this pull request.
All of this code can be deleted once we move HIP to the new driver.
https://github.com/llvm/llvm-project/pull/70201
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/70116
___
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/70116
>From 5f8318bcb3419a675680d8e58b4707d42397ae1e Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 24 Oct 2023 15:27:21 -0500
Subject: [PATCH] [Offloading][NFC] Move creation of offloading entries from
jhuber6 wrote:
> Can this stuff really be generic?
Obviously flags are going to be target dependent, but the actual form,
generation, and iteration of these can be generic. The idea is to put them all
into a single section such that we can filter out the ones that apply to
whatever runtime
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/70116
>From 8add2113864618d310e01bdbb0cf16e1847eb9a8 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 24 Oct 2023 15:27:21 -0500
Subject: [PATCH] [Offloading][NFC] Move creation of offloading entries from
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/70116
>From 2af5fc3dc871f0bc3bdfeff4ed2c08f6ccd089d5 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 24 Oct 2023 15:27:21 -0500
Subject: [PATCH] [Offloading][NFC] Move creation of offloading entries from
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/70116
>From 35347649fe160073e73c3bca96506b6fd96d8a31 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 24 Oct 2023 15:27:21 -0500
Subject: [PATCH] [Offloading][NFC] Move creation of offloading entries from
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/70116
Summary:
This patch is a first step to remove dependencies on the OpenMPIRBuilder
for creating generic offloading entires. This patch changes no
functionality and merely moves the code around. In the future the
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/68346
___
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/68346
>From 28dec98632ace2e48d57736bb9eb9db311f46aaf Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 29 Sep 2023 18:50:10 -0500
Subject: [PATCH] [libc] Enable remaining string functions on the GPU
Summary:
We
@@ -0,0 +1,80 @@
+//===-- State.cpp - OpenMP State & ICV interface - 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:
@@ -0,0 +1,80 @@
+//===-- State.cpp - OpenMP State & ICV interface - 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:
@@ -36,6 +46,15 @@ extern "C" {
#pragma omp end declare variant
#ifdef __AMDGCN__
+#pragma omp begin declare variant match(
\
+device = {arch(amdgcn)},
\
+implementation
https://github.com/jhuber6 commented:
I figured we would just have an internal implementation of `malloc` provided by
the OpenMP device runtime library. The variants make this more difficult, but
we could just use `#ifdef __AMDGPU__` instead of an OpenMP variant so we can
declare it as
@@ -0,0 +1,80 @@
+//===-- State.cpp - OpenMP State & ICV interface - 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:
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/69806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -15,9 +15,19 @@
#endif
#ifdef __cplusplus
+#include
jhuber6 wrote:
I'm unsure if there's ever a reason to include the C++ wrappers in a
freestanding environment. Without C++, these go straight to the `clang`
resource directly. With the C++ versions
@@ -48,25 +48,17 @@ namespace {
extern "C" {
[[gnu::weak, gnu::leaf]] void *malloc(uint64_t Size);
[[gnu::weak, gnu::leaf]] void free(void *Ptr);
-}
-///}
+void *llvm_device_malloc(uint64_t Size) { return allocator::alloc(Size); }
+void llvm_device_free(void *Ptr) {
@@ -16,3 +16,4 @@ free
memcmp
printf
__assert_fail
+malloc
jhuber6 wrote:
This is already in the file
https://github.com/llvm/llvm-project/pull/69806
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/66034
___
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/66034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -0,0 +1,19 @@
+//===-- Implementation of the GPU logbf function
jhuber6 wrote:
Fix header
https://github.com/llvm/llvm-project/pull/66034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/jhuber6 approved this pull request.
LG after fixing the header formatting.
https://github.com/llvm/llvm-project/pull/66034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -0,0 +1,19 @@
+//===-- Implementation of the GPU logbf function
jhuber6 wrote:
Fix header
https://github.com/llvm/llvm-project/pull/66034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -0,0 +1,21 @@
+//===-- Implementation of the GPU atan2f function
jhuber6 wrote:
Fix header
https://github.com/llvm/llvm-project/pull/66034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -0,0 +1,21 @@
+//===-- Implementation of the GPU atan2f function
jhuber6 wrote:
Fix header
https://github.com/llvm/llvm-project/pull/66034
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
@@ -0,0 +1,17 @@
+//===-- Implementation of the GPU lroundf function
jhuber6 wrote:
This and some other headers need to be reformatted.
https://github.com/llvm/llvm-project/pull/66034
___
cfe-commits mailing list
@@ -0,0 +1,17 @@
+//===-- Implementation of the GPU lroundf function
jhuber6 wrote:
This and some other headers need to be reformatted.
https://github.com/llvm/llvm-project/pull/66034
___
cfe-commits mailing list
jhuber6 wrote:
> > You could potentially link in all the symbols and internalize them
>
> That probably won't work. After they are internalized, they have internal
> linkage and cannot be used to resolve newly added call of the same function.
>
> The purpose of internalization is to allow you
jhuber6 wrote:
> > This approach assumes that whatever the function call was transformed into
> > also exists in the same library, which isn't necessarily true.
>
> True, good point. But I don't think it's necessarily due to this approach,
> but more of how AMDGPULibCalls is implemented. It
jhuber6 wrote:
> sincos() is just one example. There are several other cases that can trigger
> this issue. fold_rootn() generates new function calls for square and cubic
> roots, fold_pow() does a similar thing for specific powers (ex 2), etc.
>
> We did try disabling -amdgpu-prelink, and it
jhuber6 wrote:
> This handles the edge case where optimization introduces new device library
> functions, such as a fused sincos() from separate sin() and cos() calls.
This seems like a pretty big change to solve just this problem. Could we not
just put `nobuiltin` on said function to stop it
Author: Joseph Huber
Date: 2023-10-16T15:41:01-05:00
New Revision: b7de1d07e5298bdd97816043360ea334378f5565
URL:
https://github.com/llvm/llvm-project/commit/b7de1d07e5298bdd97816043360ea334378f5565
DIFF:
https://github.com/llvm/llvm-project/commit/b7de1d07e5298bdd97816043360ea334378f5565.diff
Author: Joseph Huber
Date: 2023-10-09T07:56:43-05:00
New Revision: 85feb9347f77859a877e767692e1c11d00cf6ffd
URL:
https://github.com/llvm/llvm-project/commit/85feb9347f77859a877e767692e1c11d00cf6ffd
DIFF:
https://github.com/llvm/llvm-project/commit/85feb9347f77859a877e767692e1c11d00cf6ffd.diff
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/65676
___
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/65676
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
I already changed the `init_fini_array_test` while I fixed an unrelated
problem, so it should be fine now.
https://github.com/llvm/llvm-project/pull/67673
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
jhuber6 wrote:
Does `thread_limit` directly imply the number of threads? I thought that it
merely set an upper bound such that it cannot be increased beyond that via
environment variables.
https://github.com/llvm/llvm-project/pull/68373
___
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/68264
___
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/68264
>From 5010ba6ec2f7370d2efc01d2fafb86d55c4dd883 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 4 Oct 2023 16:50:20 -0500
Subject: [PATCH] [OpenMP] Prevent AMDGPU from overriding visibility on
DT_nohost
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/68346
Summary:
We previously had to disable these string functions because they were
not compatible with the definitions coming from the GNU / host
environment. The GPU, when exporting its declarations, has a very
@@ -308,12 +308,13 @@ static bool requiresAMDGPUProtectedVisibility(const Decl
*D,
if (GV->getVisibility() != llvm::GlobalValue::HiddenVisibility)
return false;
- return D->hasAttr() ||
- (isa(D) && D->hasAttr()) ||
- (isa(D) &&
-
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/68264
>From ddccf41b5c3a198db80199d2432afe60c41cad7b Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 4 Oct 2023 16:50:20 -0500
Subject: [PATCH] [OpenMP] Prevent AMDGPU from overriding visibility on
DT_nohost
jhuber6 wrote:
> Can you double check this error from the linux x86_64 bot:
>
> ```
> /var/lib/buildkite-agent/builds/linux-56-7f758798dd-khkmx-1/llvm-project/github-pull-requests/libc/test/src/stdlib/rand_test.cpp:27:2:
> error: unterminated conditional directive
> --
> | #ifndef
jhuber6 wrote:
For reference, I've had similar problems in the past. Usually it happens
because the header needs to be aligned on a `uint64_t` to be read. The ELF
section has 8-byte alignment, but that can be incorrect when extracting from
something like an archive. I just make a copy in that
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/68264
>From 52d11d0d975f03a3cd2760b42236b5ec8097331b Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 4 Oct 2023 16:50:20 -0500
Subject: [PATCH 1/2] [OpenMP] Prevent AMDGPU from overriding visibility on
@@ -1,5 +1,5 @@
// RUN: %clang_cc1 -debug-info-kind=limited -verify -fopenmp -x c++ -triple
nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s
-fopenmp-is-target-device -o - | FileCheck %s
-// RUN: %clang_cc1 -debug-info-kind=limited -verify -fopenmp -x
jhuber6 wrote:
> This stuff looks very cuda/opencl specific. It's definitely surprising for
> C++ code. Do we need it for openmp? If not it seems better to guard the hack
> with visibility behind if (hip)
You reminded me that I need to refine this logic as well. What it's doing here
is
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/68264
>From 52d11d0d975f03a3cd2760b42236b5ec8097331b Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 4 Oct 2023 16:50:20 -0500
Subject: [PATCH 1/2] [OpenMP] Prevent AMDGPU from overriding visibility on
jhuber6 wrote:
ping
https://github.com/llvm/llvm-project/pull/66167
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
ping
https://github.com/llvm/llvm-project/pull/66167
___
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/66167
>From 7abe016b179a986ee6f94973a1a2c313185705f0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 12 Sep 2023 18:13:22 -0500
Subject: [PATCH] [libc] Partially implement 'rand' for the GPU
Summary:
This
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/66167
>From 7abe016b179a986ee6f94973a1a2c313185705f0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 12 Sep 2023 18:13:22 -0500
Subject: [PATCH] [libc] Partially implement 'rand' for the GPU
Summary:
This
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/68264
Summary:
There's some logic in the AMDGPU target that manually resets the
requested visibility of certain variables. This was triggering when we
set a constant variable in OpenMP. However, we shouldn't do this
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/68215
___
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/68220
___
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/68220
- [LinkerWrapper] Fix resolution of weak symbols during LTO
- [Libomptarget] Make the DeviceRTL configuration globals weak
>From f2e29b6136d245e0712bfb87de1f4253d12dd6f5 Mon Sep 17 00:00:00 2001
From: Joseph
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/68215
>From f2e29b6136d245e0712bfb87de1f4253d12dd6f5 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 4 Oct 2023 07:34:01 -0500
Subject: [PATCH] [LinkerWrapper] Fix resolution of weak symbols during LTO
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/68215
Summary:
Weak symbols are supposed to have the semantics that they can be
overriden by a strong (i.e. global) definition. This wasn't being
respected by the LTO pass because we simply used the first definition
https://github.com/jhuber6 approved this pull request.
I think in the long term we need to move away from the bundler, which would
suggest we probably want something similar in the "new driver". But overall the
changes here are pretty self contained and the concept is straightforward.
@@ -881,6 +900,184 @@ CreateFileHandler(MemoryBuffer ,
"'" + FilesType + "': invalid file type specified");
}
+OffloadBundlerConfig::OffloadBundlerConfig() {
+ auto IgnoreEnvVarOpt =
+
jhuber6 wrote:
>
> We need to support compression/uncompression of standalone bundled bitcode,
> and standalone bundled code objects that are not embedded in ELF or COFF
> binaries. An OS-neutral binary format is preferred.
I think my ideal solution would be LLVM supporting some module
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/67981
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
Ping. This is a bug fix that prevents this from actually being used and doesn't
change any existing behavior.
https://github.com/llvm/llvm-project/pull/65676
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
jhuber6 wrote:
Ping. This is a bug fix that prevents this from actually being used and doesn't
change any existing behavior.
https://github.com/llvm/llvm-project/pull/65676
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/65676
>From d11fae15878622eb2eb452aedf616e01b577e102 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 7 Sep 2023 16:08:30 -0500
Subject: [PATCH 1/2] [libc] Fix linking of AMDGPU device runtime control
constants
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/65676
>From d11fae15878622eb2eb452aedf616e01b577e102 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Thu, 7 Sep 2023 16:08:30 -0500
Subject: [PATCH 1/2] [libc] Fix linking of AMDGPU device runtime control
constants
jhuber6 wrote:
> Did you test it with internal CI? We may need some HIP header changes to
> avoid regressing existing HIP apps.
No, I don't know how to do that. Hopefully people aren't relying on this to be
included elsewhere, since its replacement in this single file is pretty
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/67981
___
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/67981
>From 3ce25920eb83ed2e859050fd24dada7b232e0431 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 2 Oct 2023 07:25:03 -0500
Subject: [PATCH] [Clang] Fix HIP wrapper inclusion of 'algorithm' when using
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/67981
Summary:
The `algorithm` header included here sometimes caused issues when using
`libc++` over `libstdc++`. This was primarily because of the order they
were included in. This patch just gets rid of this
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/67869
Summary:
We previously had to disable these string functions because they were
not compatible with the definitions coming from the GNU / host
environment. The GPU, when exporting its declarations, has a very
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/67855
___
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/67855
Summary:
The POSIX standard expects the first argument to this function to be
constant, e.g. https://man7.org/linux/man-pages/man2/nanosleep.2.html.
This fixes that problem and also corrects an obvious problem
@@ -1183,6 +1183,10 @@ def fgpu_inline_threshold_EQ : Joined<["-"],
"fgpu-inline-threshold=">,
def fgpu_sanitize : Flag<["-"], "fgpu-sanitize">, Group,
HelpText<"Enable sanitizer for supported offloading devices">;
def fno_gpu_sanitize : Flag<["-"], "fno-gpu-sanitize">,
801 - 900 of 1299 matches
Mail list logo
