Author: Joseph Huber
Date: 2020-07-18T12:55:50-04:00
New Revision: 3bbbe4c4b6c8e20538a388df164da6f8d935e0cc
URL:
https://github.com/llvm/llvm-project/commit/3bbbe4c4b6c8e20538a388df164da6f8d935e0cc
DIFF:
https://github.com/llvm/llvm-project/commit/3bbbe4c4b6c8e20538a388df164da6f8d935e0cc.diff
Author: Joseph Huber
Date: 2022-09-06T08:55:16-05:00
New Revision: 5dbc7cf7cac4428e0876a94a4fca10fe60af7328
URL:
https://github.com/llvm/llvm-project/commit/5dbc7cf7cac4428e0876a94a4fca10fe60af7328
DIFF:
https://github.com/llvm/llvm-project/commit/5dbc7cf7cac4428e0876a94a4fca10fe60af7328.diff
Author: Joseph Huber
Date: 2022-09-06T08:55:17-05:00
New Revision: a69404c0a294ce65432ce67d5f3e7dce28106496
URL:
https://github.com/llvm/llvm-project/commit/a69404c0a294ce65432ce67d5f3e7dce28106496
DIFF:
https://github.com/llvm/llvm-project/commit/a69404c0a294ce65432ce67d5f3e7dce28106496.diff
Author: Joseph Huber
Date: 2022-09-06T13:40:05-05:00
New Revision: 57ef29f2835eb594bc2ad4793df05188be4c2ef6
URL:
https://github.com/llvm/llvm-project/commit/57ef29f2835eb594bc2ad4793df05188be4c2ef6
DIFF:
https://github.com/llvm/llvm-project/commit/57ef29f2835eb594bc2ad4793df05188be4c2ef6.diff
Author: Joseph Huber
Date: 2022-09-06T13:56:24-05:00
New Revision: 3a623999f3ff96843f97ee300e0c94b8cbc88a9f
URL:
https://github.com/llvm/llvm-project/commit/3a623999f3ff96843f97ee300e0c94b8cbc88a9f
DIFF:
https://github.com/llvm/llvm-project/commit/3a623999f3ff96843f97ee300e0c94b8cbc88a9f.diff
Author: Joseph Huber
Date: 2022-09-06T19:49:47-05:00
New Revision: 2753eafe5a7f003776b12f425c5b0a475e8fb6b7
URL:
https://github.com/llvm/llvm-project/commit/2753eafe5a7f003776b12f425c5b0a475e8fb6b7
DIFF:
https://github.com/llvm/llvm-project/commit/2753eafe5a7f003776b12f425c5b0a475e8fb6b7.diff
Author: Joseph Huber
Date: 2022-09-06T20:14:20-05:00
New Revision: a6bb7c22fc288686010076ac253a12b4b1cd2ee5
URL:
https://github.com/llvm/llvm-project/commit/a6bb7c22fc288686010076ac253a12b4b1cd2ee5
DIFF:
https://github.com/llvm/llvm-project/commit/a6bb7c22fc288686010076ac253a12b4b1cd2ee5.diff
Author: Joseph Huber
Date: 2022-09-06T20:31:27-05:00
New Revision: 7354a73945f1c123d66b01f51374ecbdba18fab3
URL:
https://github.com/llvm/llvm-project/commit/7354a73945f1c123d66b01f51374ecbdba18fab3
DIFF:
https://github.com/llvm/llvm-project/commit/7354a73945f1c123d66b01f51374ecbdba18fab3.diff
Author: Joseph Huber
Date: 2022-09-14T09:42:06-05:00
New Revision: 194ec844f5c67306f505a3418038c5e75859bad8
URL:
https://github.com/llvm/llvm-project/commit/194ec844f5c67306f505a3418038c5e75859bad8
DIFF:
https://github.com/llvm/llvm-project/commit/194ec844f5c67306f505a3418038c5e75859bad8.diff
Author: Joseph Huber
Date: 2022-09-14T10:14:43-05:00
New Revision: bae1a2cf3cce529b0d03df8bac962d13b407e117
URL:
https://github.com/llvm/llvm-project/commit/bae1a2cf3cce529b0d03df8bac962d13b407e117
DIFF:
https://github.com/llvm/llvm-project/commit/bae1a2cf3cce529b0d03df8bac962d13b407e117.diff
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/71234
___
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/69371
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1035,6 +1043,13 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
}
+ // Re-link against any bitcodes supplied via the -mlink-builtin-bitcode
option
+ // Some optimizations may generate new function calls that would not have
+ // been linked pre-optimization
https://github.com/jhuber6 commented:
Some comments. I remember there was a reason we couldn't use the existing
linking support and needed the new pass, what was that again?
https://github.com/llvm/llvm-project/pull/69371
___
cfe-commits mailing list
@@ -1035,6 +1043,13 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
}
}
+ // Re-link against any bitcodes supplied via the -mlink-builtin-bitcode
option
+ // Some optimizations may generate new function calls that would not have
+ // been linked pre-optimization
@@ -45,7 +46,8 @@ namespace clang {
const TargetOptions &TOpts, const LangOptions &LOpts,
StringRef TDesc, llvm::Module *M, BackendAction
Action,
llvm::IntrusiveRefCntPtr VFS,
-
@@ -48,428 +49,369 @@
#include "llvm/Support/ToolOutputFile.h"
#include "llvm/Support/YAMLTraits.h"
#include "llvm/Transforms/IPO/Internalize.h"
+#include "llvm/Transforms/Utils/Cloning.h"
-#include
#include
using namespace clang;
using namespace llvm;
#define DEBUG_T
@@ -155,10 +162,10 @@ class EmitAssemblyHelper {
return F;
}
- void
- RunOptimizationPipeline(BackendAction Action,
+ void RunOptimizationPipeline(BackendAction Action,
std::unique_ptr &OS,
- std::unique_ptr &ThinLin
@@ -0,0 +1,29 @@
+//===-- LinkInModulesPass.cpp - Module Linking pass --- 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: Apa
https://github.com/jhuber6 approved this pull request.
I'm not entirely happy with the existence of this hack, but it's an ugly
solution to an ugly self-inflicted problem, so I can live with it for now.
https://github.com/llvm/llvm-project/pull/69371
jhuber6 wrote:
The code formatter says that it's not happy. Can you try `git clang-format
HEAD~1` in your branch?
https://github.com/llvm/llvm-project/pull/69371
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/ma
jhuber6 wrote:
> I am getting this from the formatter:
>
> ```
> - void RunOptimizationPipeline(BackendAction Action,
> - std::unique_ptr &OS,
> - std::unique_ptr &ThinLinkOS,
> - BackendConsumer *BC);
> + void RunOptim
jhuber6 wrote:
> > Just do what the formatter says, not every file is 100% clang-formatted so
> > there's bits of old code that haven't been properly cleaned yet. This was
> > the same line that I thought looked wrong so it should probably be fixed.
> > Using `git clang-format HEAD~1` only for
jhuber6 wrote:
> That said, I definitely don't want this to be a barrier to getting this patch
> in, so if you still feel like we should go with the clang-format
> recommendation, I'll change it and also update the EmitAssembly and
> EmitBackendOutput signatures which were flagged by clang-for
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/71739
- [NVPTX] Allow the ctor/dtor lowering pass to emit kernels
- [OpenMP] Rework handling of global ctor/dtors in OpenMP
>From c1505a29d542bebd5c5e81d231e633c518b08caf Mon Sep 17 00:00:00 2001
From: Joseph Huber
D
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/71739
>From 6be02dce45d672dd358bc277c97815cb201c4d0b Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 7 Nov 2023 17:12:31 -0600
Subject: [PATCH] [OpenMP] Rework handling of global ctor/dtors in OpenMP
Summary:
T
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/71739
___
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/71739
>From a9f8285ecef2d43c6ccd87a1be9f795d566ed9e8 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 7 Nov 2023 17:12:31 -0600
Subject: [PATCH] [OpenMP] Rework handling of global ctor/dtors in OpenMP
Summary:
T
@@ -95,7 +95,7 @@ using namespace llvm;
static cl::opt
LowerCtorDtor("nvptx-lower-global-ctor-dtor",
cl::desc("Lower GPU ctor / dtors to globals on the device."),
- cl::init(false), cl::Hidden);
+ cl::init(true), cl::Hidde
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/71739
>From 159031c4c880e552ea90ec8ab6f6ed328c09ff10 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 7 Nov 2023 17:12:31 -0600
Subject: [PATCH] [OpenMP] Rework handling of global ctor/dtors in OpenMP
Summary:
T
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/71739
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -95,7 +95,7 @@ using namespace llvm;
static cl::opt
LowerCtorDtor("nvptx-lower-global-ctor-dtor",
cl::desc("Lower GPU ctor / dtors to globals on the device."),
- cl::init(false), cl::Hidden);
+ cl::init(true), cl::Hidde
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/71739
>From 07a74b4561f2eb4f8debd40c7c2313da7b7fb0eb Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 7 Nov 2023 17:12:31 -0600
Subject: [PATCH] [OpenMP] Rework handling of global ctor/dtors in OpenMP
Summary:
T
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/71739
>From 5e378ae3efdebedb044528167131c8cae4571a59 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 7 Nov 2023 17:12:31 -0600
Subject: [PATCH] [OpenMP] Rework handling of global ctor/dtors in OpenMP
Summary:
T
@@ -2627,6 +2637,48 @@ struct AMDGPUDeviceTy : public GenericDeviceTy,
AMDGenericDeviceTy {
using AMDGPUEventRef = AMDGPUResourceRef;
using AMDGPUEventManagerTy = GenericDeviceResourceManagerTy;
+ /// Common method to invoke a single threaded constructor or destructor
+
@@ -2627,6 +2637,48 @@ struct AMDGPUDeviceTy : public GenericDeviceTy,
AMDGenericDeviceTy {
using AMDGPUEventRef = AMDGPUResourceRef;
using AMDGPUEventManagerTy = GenericDeviceResourceManagerTy;
+ /// Common method to invoke a single threaded constructor or destructor
+
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/71739
>From 0a1f4b5d514a5e1525e3178a80f6e8f5638bfb69 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 7 Nov 2023 17:12:31 -0600
Subject: [PATCH] [OpenMP] Rework handling of global ctor/dtors in OpenMP
Summary:
T
@@ -671,6 +671,20 @@ struct GenericDeviceTy : public DeviceAllocatorTy {
Error synchronize(__tgt_async_info *AsyncInfo);
virtual Error synchronizeImpl(__tgt_async_info &AsyncInfo) = 0;
+ /// Invokes any global constructors on the device if present and is required
+ /// b
@@ -2794,6 +2794,14 @@ void ItaniumCXXABI::registerGlobalDtor(CodeGenFunction
&CGF, const VarDecl &D,
if (D.isNoDestroy(CGM.getContext()))
return;
+ // OpenMP offloading supports C++ constructors and destructors but we do not
+ // always have 'atexit' available. Inste
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/71739
>From 5283c5e08877b11a0eece51ca3877c9f5f8c7b82 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 7 Nov 2023 17:12:31 -0600
Subject: [PATCH] [OpenMP] Rework handling of global ctor/dtors in OpenMP
Summary:
T
@@ -2794,6 +2794,14 @@ void ItaniumCXXABI::registerGlobalDtor(CodeGenFunction
&CGF, const VarDecl &D,
if (D.isNoDestroy(CGM.getContext()))
return;
+ // OpenMP offloading supports C++ constructors and destructors but we do not
+ // always have 'atexit' available. Inste
@@ -98,6 +100,11 @@ extern cl::opt PrintPipelinePasses;
static cl::opt ClSanitizeOnOptimizerEarlyEP(
"sanitizer-early-opt-ep", cl::Optional,
cl::desc("Insert sanitizers on OptimizerEarlyEP."), cl::init(false));
+
+// Re-link builtin bitcodes after optimization
+static c
jhuber6 wrote:
Just noticed I'm actually calling the destructors backwards in AMDGPU. Will fix
that.
https://github.com/llvm/llvm-project/pull/71739
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinf
@@ -2794,6 +2794,14 @@ void ItaniumCXXABI::registerGlobalDtor(CodeGenFunction
&CGF, const VarDecl &D,
if (D.isNoDestroy(CGM.getContext()))
return;
+ // OpenMP offloading supports C++ constructors and destructors but we do not
+ // always have 'atexit' available. Inste
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/71739
>From c3df637dd2cb9a5210cb90a3bb69a63c31236039 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 7 Nov 2023 17:12:31 -0600
Subject: [PATCH] [OpenMP] Rework handling of global ctor/dtors in OpenMP
Summary:
T
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/71739
>From 45a645c4e65d3b1f98dee23c2eba1cf6db99bff0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 7 Nov 2023 17:12:31 -0600
Subject: [PATCH] [OpenMP] Rework handling of global ctor/dtors in OpenMP
Summary:
T
@@ -2794,6 +2794,14 @@ void ItaniumCXXABI::registerGlobalDtor(CodeGenFunction
&CGF, const VarDecl &D,
if (D.isNoDestroy(CGM.getContext()))
return;
+ // OpenMP offloading supports C++ constructors and destructors but we do not
+ // always have 'atexit' available. Inste
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/71739
>From 45a645c4e65d3b1f98dee23c2eba1cf6db99bff0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 7 Nov 2023 17:12:31 -0600
Subject: [PATCH 1/2] [OpenMP] Rework handling of global ctor/dtors in OpenMP
Summar
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/71739
>From 45a645c4e65d3b1f98dee23c2eba1cf6db99bff0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 7 Nov 2023 17:12:31 -0600
Subject: [PATCH 1/2] [OpenMP] Rework handling of global ctor/dtors in OpenMP
Summar
@@ -1038,6 +1048,109 @@ struct CUDADeviceTy : public GenericDeviceTy {
using CUDAStreamManagerTy = GenericDeviceResourceManagerTy;
using CUDAEventManagerTy = GenericDeviceResourceManagerTy;
+ Error callGlobalCtorDtorCommon(GenericPluginTy &Plugin, DeviceImageTy &Image,
+
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/71739
>From 5366317448060c928ec415f7e243a402ef181cb5 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 7 Nov 2023 17:12:31 -0600
Subject: [PATCH] [OpenMP] Rework handling of global ctor/dtors in OpenMP
Summary:
T
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/71739
>From e0281fc280385286c3d5da7de619e793bd3b6bea Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 7 Nov 2023 17:12:31 -0600
Subject: [PATCH] [OpenMP] Rework handling of global ctor/dtors in OpenMP
Summary:
T
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/71739
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> Would it be feasible to consider switching to the new offloading driver mode
> and really link with the library instead? It may be a conveniently isolated
> use case with little/no existing users that would disrupt.
I've thought a reasonable amount about a `compiler-rt` for GP
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/72280
Summary:
The standard GNU atomic operations are a very common way to target
hardware atomics on the device. With more hetergenous devices being
introduced, the concept of memory scopes has been in the LLVM languag
https://github.com/jhuber6 approved this pull request.
Thanks, I noticed that spurious failure as well but didn't know what caused it.
https://github.com/llvm/llvm-project/pull/74504
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
jhuber6 wrote:
Ping
https://github.com/llvm/llvm-project/pull/73177
___
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/72280
___
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/73177
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
I got this fail just now after doing a pull.
```
FAIL: Clang :: Driver/hip-offload-compress-zstd.hip (477 of 1078)
TEST 'Clang :: Driver/hip-offload-compress-zstd.hip'
FAILED
Exit Code: 1
Command Output (stderr):
--
RUN: at line 7: rm -rf
Author: Joseph Huber
Date: 2023-12-07T16:55:14-06:00
New Revision: bfd41c3f8cc70bd65461a6d767f55c14d72150d9
URL:
https://github.com/llvm/llvm-project/commit/bfd41c3f8cc70bd65461a6d767f55c14d72150d9
DIFF:
https://github.com/llvm/llvm-project/commit/bfd41c3f8cc70bd65461a6d767f55c14d72150d9.diff
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/74783
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -80,8 +85,10 @@ class NVPTXSubtarget : public NVPTXGenSubtargetInfo {
bool allowFP16Math() const;
bool hasMaskOperator() const { return PTXVersion >= 71; }
bool hasNoReturn() const { return SmVersion >= 30 && PTXVersion >= 64; }
- unsigned int getSmVersion() const { r
@@ -80,8 +85,10 @@ class NVPTXSubtarget : public NVPTXGenSubtargetInfo {
bool allowFP16Math() const;
bool hasMaskOperator() const { return PTXVersion >= 71; }
bool hasNoReturn() const { return SmVersion >= 30 && PTXVersion >= 64; }
- unsigned int getSmVersion() const { r
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/74895
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Joseph Huber
Date: 2023-12-11T07:56:19-06:00
New Revision: ef23bba6e5aecbc6008e8a9ff8740fc4b04fe814
URL:
https://github.com/llvm/llvm-project/commit/ef23bba6e5aecbc6008e8a9ff8740fc4b04fe814
DIFF:
https://github.com/llvm/llvm-project/commit/ef23bba6e5aecbc6008e8a9ff8740fc4b04fe814.diff
Author: Joseph Huber
Date: 2023-11-14T11:52:43-06:00
New Revision: f3d57583b4942056a930b6f1e4101063637e9e98
URL:
https://github.com/llvm/llvm-project/commit/f3d57583b4942056a930b6f1e4101063637e9e98
DIFF:
https://github.com/llvm/llvm-project/commit/f3d57583b4942056a930b6f1e4101063637e9e98.diff
jhuber6 wrote:
> Just a FYI, that recent NVIDIA GPUs have introduced a concept of [thread
> block
> cluster](https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#thread-block-clusters).
> We may need another level of granularity between the block and device.
Should be easy enough,
jhuber6 wrote:
> Is there any actual difference now between these and the HIP/OpenCL flavors
> other than dropping the language from the name?
Yes, these directly copy the GNU functions and names. The OpenCL / HIP ones use
a different format.
https://github.com/llvm/llvm-project/pull/72280
__
@@ -798,6 +798,13 @@ static void InitializePredefinedMacros(const TargetInfo
&TI,
Builder.defineMacro("__ATOMIC_ACQ_REL", "4");
Builder.defineMacro("__ATOMIC_SEQ_CST", "5");
+ // Define macros for the clang atomic scopes.
+ Builder.defineMacro("__MEMORY_SCOPE_SYSTEM", "
@@ -205,6 +220,56 @@ class AtomicScopeHIPModel : public AtomicScopeModel {
}
};
+/// Defines the generic atomic scope model.
+class AtomicScopeGenericModel : public AtomicScopeModel {
+public:
+ /// The enum values match predefined built-in macros __ATOMIC_SCOPE_*.
+ enum
@@ -54,6 +59,16 @@ enum class SyncScope {
inline llvm::StringRef getAsString(SyncScope S) {
jhuber6 wrote:
I think it's because this is for AST printing purposes, while the backend
strings vary per target.
https://github.com/llvm/llvm-project/pull/72280
@@ -904,6 +904,32 @@ BUILTIN(__atomic_signal_fence, "vi", "n")
BUILTIN(__atomic_always_lock_free, "bzvCD*", "nE")
BUILTIN(__atomic_is_lock_free, "bzvCD*", "nE")
+// GNU atomic builtins with atomic scopes.
+ATOMIC_BUILTIN(__scoped_atomic_load, "v.", "t")
jhuber
jhuber6 wrote:
> Overall I think it is the right way to go. Memory scope has been used by
> different offloading languages and the atomic clang builtins are essentially
> the same. Adding a generic clang atomic builtins with memory scope allows
> code sharing among offloading languages.
I agr
https://github.com/jhuber6 commented:
This being in clang instead seems like a good change. Are there no CodeGen
tests changed? We should add one if so. Probably just take your `libomptarget`
test and run `update_cc_test_checks` on it with the arguments found in other
test files.
https://gi
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/72442
Summary:
Currently the linker wrapper strictly assigns a single input binary to a
single link job based off of its input architecture. This is not
sufficient to implement the AMDGPU target ID correctly as this cou
jhuber6 wrote:
The Windows builder gives the following error which I don't relieve on Linux.
Does anyone have any clue what this `invalid argument` error could be caused by?
```
# note: command had no output on stdout or stderr
# error: command failed with exit status: 1
# executed command: 'c:\
jhuber6 wrote:
> the error msg is not generated by offload wrapper itself, right? is it from
> some program called by the offload wrapper?
It may be caused by the `clang` invocation. Though I'm unsure why this change
causes that test to fail.
https://github.com/llvm/llvm-project/pull/72442
__
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/72544
Summary:
This patch is a simple refactoring of code out of the linker wrapper
into a common location. The main motivation behind this change is to
make it easier to change the handling in the future to accept a tr
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/72554
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2458,6 +2458,11 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
&getTarget().getLongDoubleFormat() == &llvm::APFloat::IEEEquad())
BuiltinID = mutateLongDoubleBuiltin(BuiltinID);
+ // Mutate the printf builtin ID so that we u
https://github.com/jhuber6 commented:
Any tests? Can you explain why it's not sufficient to do this lowering in the
AMDGPU pass?
https://github.com/llvm/llvm-project/pull/72554
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
@@ -2458,6 +2458,11 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl
GD, unsigned BuiltinID,
&getTarget().getLongDoubleFormat() == &llvm::APFloat::IEEEquad())
BuiltinID = mutateLongDoubleBuiltin(BuiltinID);
+ // Mutate the printf builtin ID so that we u
jhuber6 wrote:
> I'm a little wary of adding these without actually going through any sort of
> standardization process; if other vendors don't support the same interface,
> we just have more variations. (See also
> https://clang.llvm.org/get_involved.html#criteria )
>
> How consistent are th
jhuber6 wrote:
> > I figured we can just treat these as clang extensions for the time being.
> > We already have two variants that are more or less redundant for specific
> > use-cases, (OpenCL and HIP), which should be able to be removed after this.
>
> I'm not sure what you mean here. If you
jhuber6 wrote:
> > The underlying implementation is a string literal in the LLVM syncscope
> > argument, but the problem is that this isn't standardized at all and varies
> > between backends potentially
>
> We don't have to use the same set of strings as syncscope if that doesn't
> make sens
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/72544
___
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/72697
Summary:
This patch provides the initial support to allow handling the new
driver's offloading entries. Normally, the ELF target can emit varibles
at C-identifier named sections and the linker will provide a point
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/72889
Summary:
The linker wrapper is a utility used to create offloading programs from
single-source offloading languages such as OpenMP or CUDA. This is done
by embedding device code into the host object, then feeding
Author: Joseph Huber
Date: 2023-11-20T11:22:59-06:00
New Revision: 88b672b0a79e9f68253abf7edcfa5a42d1321cae
URL:
https://github.com/llvm/llvm-project/commit/88b672b0a79e9f68253abf7edcfa5a42d1321cae
DIFF:
https://github.com/llvm/llvm-project/commit/88b672b0a79e9f68253abf7edcfa5a42d1321cae.diff
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/72889
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -62,35 +63,51 @@ void offloading::emitOffloadingEntry(Module &M, Constant
*Addr, StringRef Name,
M.getDataLayout().getDefaultGlobalsAddressSpace());
// The entry has to be created in the section the linker expects it to be.
- Entry->setSection(SectionName);
+ if
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/72697
>From ef4e04961a1f553a9f1dced26e69e927060d4dd7 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 17 Nov 2023 14:09:59 -0600
Subject: [PATCH] [Offload] Initial support for registering offloading entries
on C
@@ -62,35 +63,51 @@ void offloading::emitOffloadingEntry(Module &M, Constant
*Addr, StringRef Name,
M.getDataLayout().getDefaultGlobalsAddressSpace());
// The entry has to be created in the section the linker expects it to be.
- Entry->setSection(SectionName);
+ if
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/72697
>From e3b6ab18f390e0ee4938095717aa9e4b21690aa7 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 17 Nov 2023 14:09:59 -0600
Subject: [PATCH] [Offload] Initial support for registering offloading entries
on C
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/72697
>From 4627ea74d753eb6742051127e0a5b0c64a620f20 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 17 Nov 2023 14:09:59 -0600
Subject: [PATCH] [Offload] Initial support for registering offloading entries
on C
@@ -62,35 +63,51 @@ void offloading::emitOffloadingEntry(Module &M, Constant
*Addr, StringRef Name,
M.getDataLayout().getDefaultGlobalsAddressSpace());
// The entry has to be created in the section the linker expects it to be.
- Entry->setSection(SectionName);
+ if
@@ -126,3 +126,8 @@ def version : Flag<["--", "-"], "version">,
Flags<[HelpHidden]>, Alias;
def whole_archive : Flag<["--", "-"], "whole-archive">, Flags<[HelpHidden]>;
def no_whole_archive : Flag<["--", "-"], "no-whole-archive">,
Flags<[HelpHidden]>;
+
+// COFF-style linker
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/72889
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> The command-line argument handling is not related to
> [PE](https://en.wikipedia.org/wiki/Portable_Executable)/COFF, but to
> Microsoft's `link.exe` command line interface, for instance
> [`/libpath:`](https://learn.microsoft.com/en-us/cpp/build/reference/libpath-additional-li
1 - 100 of 2462 matches
Mail list logo
