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 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://lists.llvm.org/cg
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://clang.llvm.org/docs/Offloadi
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
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/72280
>From b244d36e78cf3e496a41369855e294a6e5765c6d Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 6 Nov 2023 07:08:18 -0600
Subject: [PATCH] [Clang] Introduce scoped variants of GNU atomic functions
Summary:
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/72889
>From d06171561581d9d15c14f756c8999b478e1d769e Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 20 Nov 2023 10:12:04 -0600
Subject: [PATCH 1/2] [LinkerWrapper] Accenp some neede COFF linker argument
Summar
jhuber6 wrote:
Do COFF / Windows libraries have a special file magic / handling? I may need to
update the extraction code to handle those in a later patch.
https://github.com/llvm/llvm-project/pull/72889
___
cfe-commits mailing list
cfe-commits@lists.
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/73177
Summary:
This patch adds support for registering texture / surface variables from
CUDA / HIP. Additionally, we now properly track the `extern` and `const`
flags that are also used in these runtime functions.
This
https://github.com/jhuber6 closed
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
@@ -458,44 +459,39 @@ void createRegisterFatbinFunction(Module &M,
GlobalVariable *FatbinDesc,
DtorFunc->setSection(".text.startup");
// Get the __cudaRegisterFatBinary function declaration.
- auto *RegFatTy = FunctionType::get(PointerType::getUnqual(C)->getPointerTo(),
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/73374
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -457,45 +457,42 @@ void createRegisterFatbinFunction(Module &M,
GlobalVariable *FatbinDesc,
IsHIP ? ".hip.fatbin_unreg" : ".cuda.fatbin_unreg", &M);
DtorFunc->setSection(".text.startup");
+ auto *PtrTy = PointerType::getUnqual(C);
+
// Get the
https://github.com/jhuber6 approved this pull request.
Thanks, this was never properly cleaned up after moving to opaque pointers.
https://github.com/llvm/llvm-project/pull/73374
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
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
jhuber6 wrote:
Ping
https://github.com/llvm/llvm-project/pull/73030
___
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.
AFAIK this is the correct way to set debug information for something that
doesn't have a valid source location like a lot of generated OpenMP calls.
https://github.com/llvm/llvm-project/pull/73856
___
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/73856
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> My primary concerns here are:
>
> * It being likely these builtins will be superseded by something else
> once someone else tries to standardize this. Maybe this isn't a big deal...
> but maybe we want to choose names that are less likely to overlap with stuff
> anyone e
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/72280
>From ce494cd3f50720b6ba2b8a689f30272c09c06d00 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 6 Nov 2023 07:08:18 -0600
Subject: [PATCH] [Clang] Introduce scoped variants of GNU atomic functions
Summary:
https://github.com/jhuber6 commented:
Why couldn't you have put this logic in `addLTOOptions`? Seems like it's
copy-pasted verbatim at every site now.
AMD should handle very similarly to Linux here. They both compile down to
LLVM-IR and get sent to `ld.lld`.
https://github.com/llvm/llvm-proje
jhuber6 wrote:
Did this change anything for the `scoped_atomic_compare_exchange_n` variant I
added recently?
https://github.com/llvm/llvm-project/pull/74959
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman
jhuber6 wrote:
Is generic the best name here? I feel like that's going to be heavily
overloaded.
https://github.com/llvm/llvm-project/pull/75357
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cf
jhuber6 wrote:
> Is generic the best name here? I feel like that's going to be heavily
> overloaded. I'd much prefer a new architecture that just treats "SPIR-V" as a
> single architecture. E.g. `--offload-arch=spirv` or something.
https://github.com/llvm/llvm-project/pull/75357
_
jhuber6 wrote:
I feel like we should treat `spirv` in the same way we handle stuff like
`sm_90` in the `CudaArch` enum. (We should probably also rename that as it's
used for generic offloading now). OpenMP infers the triple from the arch, so in
the future when OpenMP can handle SPIR-V we can s
jhuber6 wrote:
> Perhaps we should consider prefixing it in some way (e.g. `hip-spirv` or
> `amd-spirv`) that leaves the door open for some special handling (enable a
> particular set of extensions only for amdgpu targeting SPIRV, try to deal
> with missing builtins etc.) / flexibility?
Unsur
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/75363
>From 2700151916b0fd91c793930127412af5690c9e41 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Wed, 13 Dec 2023 11:35:13 -0600
Subject: [PATCH 1/2] [LLVM] Add file magic detection for SPIR-V files.
Summary:
Mo
jhuber6 wrote:
Added a test, for whatever reason I had to do a completely clean build to get
the test to correctly pick up my changes to `Magic.cpp`, don't know why.
https://github.com/llvm/llvm-project/pull/75363
___
cfe-commits mailing list
cfe-comm
@@ -209,6 +210,13 @@ void AMDGCN::Linker::ConstructJob(Compilation &C, const
JobAction &JA,
if (JA.getType() == types::TY_LLVM_BC)
return constructLlvmLinkCommand(C, JA, Inputs, Output, Args);
+ if (Args.getLastArgValue(options::OPT_mcpu_EQ) == "generic") {
+llvm::
@@ -129,6 +129,22 @@ AMDGPUOpenMPToolChain::GetCXXStdlibType(const ArgList
&Args) const {
void AMDGPUOpenMPToolChain::AddClangSystemIncludeArgs(
const ArgList &DriverArgs, ArgStringList &CC1Args) const {
HostTC.AddClangSystemIncludeArgs(DriverArgs, CC1Args);
+
+ CC1Args
@@ -129,6 +129,22 @@ AMDGPUOpenMPToolChain::GetCXXStdlibType(const ArgList
&Args) const {
void AMDGPUOpenMPToolChain::AddClangSystemIncludeArgs(
const ArgList &DriverArgs, ArgStringList &CC1Args) const {
HostTC.AddClangSystemIncludeArgs(DriverArgs, CC1Args);
+
+ CC1Args
@@ -3381,6 +3381,8 @@ def fopenmp_cuda_blocks_per_sm_EQ : Joined<["-"],
"fopenmp-cuda-blocks-per-sm=">
Flags<[NoArgumentUnused, HelpHidden]>, Visibility<[ClangOption, CC1Option]>;
def fopenmp_cuda_teams_reduction_recs_num_EQ : Joined<["-"],
"fopenmp-cuda-teams-reduction-recs
@@ -3381,6 +3381,8 @@ def fopenmp_cuda_blocks_per_sm_EQ : Joined<["-"],
"fopenmp-cuda-blocks-per-sm=">
Flags<[NoArgumentUnused, HelpHidden]>, Visibility<[ClangOption, CC1Option]>;
def fopenmp_cuda_teams_reduction_recs_num_EQ : Joined<["-"],
"fopenmp-cuda-teams-reduction-recs
@@ -47,7 +47,9 @@ PluginAdaptorTy::create(const std::string &Name) {
new PluginAdaptorTy(Name, std::move(LibraryHandler)));
if (auto Err = PluginAdaptor->init())
return Err;
- return PluginAdaptor;
jhuber6 wrote:
Does putting `std::move` here not
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/75528
___
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/75528
___
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/75757
Summary:
The CPU target currently inherits all the libraries from the normal link
job to ensure that it has access to the same envrionment that the host
does. However, this previously was not respecting argument l
jhuber6 wrote:
> This fails for me on the host and the AMD GPU: GPU:
>
> ```
> # | :217:1: note: possible intended match here
> # | dat.datum[dat.arr[0][0]] = 5
> ```
>
> X86:
>
> ```
> # | :134:1: note: possible intended match here
> # | dat.datum[dat.arr[0][0]] = 5461
> ```
>
> The location
https://github.com/jhuber6 commented:
Needs a test. There should be some difference in codegen we can key off of.
https://github.com/llvm/llvm-project/pull/76571
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
jhuber6 wrote:
> Is the approach taken in this approach acceptable as opposed to the header
> solution I put up earlier?
Yes, it's pretty much exactly what I had in mind from my suggestion in the last
PR. Thanks.
https://github.com/llvm/llvm-project/pull/76571
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/76587
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -428,13 +428,22 @@ std::string getPGOFuncNameVarName(StringRef FuncName,
return VarName;
}
+bool isGPUProfTarget(const Module &M) {
+ const auto &triple = M.getTargetTriple();
+ return triple.rfind("nvptx", 0) == 0 || triple.rfind("amdgcn", 0) == 0 ||
+ triple.r
@@ -959,8 +959,14 @@ void CodeGenPGO::emitCounterIncrement(CGBuilderTy
&Builder, const Stmt *S,
unsigned Counter = (*RegionCounterMap)[S];
- llvm::Value *Args[] = {FuncNameVar,
- Builder.getInt64(FunctionHash),
+ // Make sure that pointer to globa
@@ -0,0 +1,21 @@
+//=== Profiling.h - OpenMP 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: Apa
https://github.com/jhuber6 commented:
Some quick nits, will look more later.
https://github.com/llvm/llvm-project/pull/76587
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
>
> How about using `--offload=` which can take a target triple? E.g.
>
> * `--offload=spirv64-amd` or something like that: pick HIPAMD tool chain.
>
> * `--offload=spirv64`: pick HIPSPV tool chain.
>
>
> And also remove this
> [limitation](https://github.com/llvm/llv
jhuber6 wrote:
Test should probably show that IR is equivalent to `#pragma omp requires
unified_shared_memory` or however that's spelled. Basic documentation should be
provided by the help test in the new flag, but we probably have somewhere in
the OpenMP docs you could add it to if desired.
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/77003
Summary:
We use the OffloadBinary to contain bundled offloading objects used to
support many images / targets at the same time. The `__tgt_device_info`
struct used to contain a pointer to this underlying binary fo
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
@@ -58,6 +60,22 @@ class GlobalTy {
void setPtr(void *P) { Ptr = P; }
};
+typedef void *IntPtrT;
jhuber6 wrote:
What's the utility of this?
https://github.com/llvm/llvm-project/pull/76587
___
cfe-commits mailing
@@ -58,6 +60,22 @@ class GlobalTy {
void setPtr(void *P) { Ptr = P; }
};
+typedef void *IntPtrT;
+struct __llvm_profile_data {
+#define INSTR_PROF_DATA(Type, LLVMType, Name, Initializer) Type Name;
+#include "llvm/ProfileData/InstrProfData.inc"
+};
+
+/// PGO profiling data
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
https://github.com/jhuber6 approved this pull request.
TYVM for fixing this. There's a lot of hacky stuff we need to do here to make
it work, but it is what it is.
Guessing the other wrapped files are fine? I remember having problems with
`cytype` and `string` but I hopefully resolved a lot of
@@ -58,6 +60,22 @@ class GlobalTy {
void setPtr(void *P) { Ptr = P; }
};
+typedef void *IntPtrT;
+struct __llvm_profile_data {
+#define INSTR_PROF_DATA(Type, LLVMType, Name, Initializer) Type Name;
+#include "llvm/ProfileData/InstrProfData.inc"
+};
+
+/// PGO profiling data
@@ -58,6 +60,22 @@ class GlobalTy {
void setPtr(void *P) { Ptr = P; }
};
+typedef void *IntPtrT;
jhuber6 wrote:
Okay. you should use the C++ `using` keyword instead of C's `typedef.
https://github.com/llvm/llvm-project/pull/76587
__
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/76587
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -163,3 +163,87 @@ Error
GenericGlobalHandlerTy::readGlobalFromImage(GenericDeviceTy &Device,
return Plugin::success();
}
+
+bool GenericGlobalHandlerTy::hasProfilingGlobals(GenericDeviceTy &Device,
+ DeviceImageTy &Image) {
https://github.com/jhuber6 approved this pull request.
Accepting this with Fortran makes sense. This option basically controls whether
or not the GPU toolchain will implicitly include the `libcgpu.a` static library
via `-lcgpu`. It defaults to on if it finds the `libc` wrapper headers in the
`
jhuber6 wrote:
> Makes sense to me, though this is not my area of expertise. Could you add a
> bit more elaborate test? Perhaps something that would check the linker
> invocation>?
I'm not familiar with how Fortran handles stuff here. It's tested in the
`clang` portion at least. The handling
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/77003
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> I am gonna sign off for the weekend as it's quite late here, so I'll reply in
> a little more detail on Monday and update the PR further. but I'd be happy to
> add a further flang test, although not too sure what it'd be, so suggestions
> are welcome.
>
> I tested this with a
jhuber6 wrote:
> Are we assuming any particular relationship to __builtin_readcyclecounter in
> terms of scales etc?
>
> __builtin_readsteadycounter could be used to access x86 MPERF clock counters,
> but to access the corresponding APERF clock we'd then need a
> __builtin_readvariablecounter
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81331
>From 30341079e795c2668588b791f2c97b44006e7a04 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 9 Feb 2024 16:13:42 -0600
Subject: [PATCH] [WIP][LLVM] Add `__builtin_readsteadycounter` intrinsic and
buiilt
Author: Joseph Huber
Date: 2024-02-12T08:15:48-06:00
New Revision: f5fd0deb2371d0bae3bef2563f50e005a140fc6d
URL:
https://github.com/llvm/llvm-project/commit/f5fd0deb2371d0bae3bef2563f50e005a140fc6d
DIFF:
https://github.com/llvm/llvm-project/commit/f5fd0deb2371d0bae3bef2563f50e005a140fc6d.diff
jhuber6 wrote:
> New intrinsic sounds right - a constant frequency counter is a different
> thing to a variable frequency counter.
>
> "Steady" implies unchanging, so I'd agree with `readfixedfreqtimer` or
> similar.
I think `steady` has sufficient context here, (i.e.
https://en.cppreference
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81331
>From 50c0bacb8c33ff0c3caf5554bd198904839a2d2c Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 9 Feb 2024 16:13:42 -0600
Subject: [PATCH] [WIP][LLVM] Add `__builtin_readsteadycounter` intrinsic and
buiilt
@@ -2764,6 +2764,37 @@ Query for this feature with
``__has_builtin(__builtin_readcyclecounter)``. Note
that even if present, its use may depend on run-time privilege or other OS
controlled state.
+``__builtin_readsteadycounter``
+--
+
+``__builtin_
@@ -104,6 +104,7 @@ std::string SDNode::getOperationName(const SelectionDAG *G)
const {
case ISD::ATOMIC_STORE: return "AtomicStore";
case ISD::PCMARKER: return "PCMarker";
case ISD::READCYCLECOUNTER: return "ReadCycleCounter";
+
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81331
>From 4a0ee4be9690e0665ca93d63ffdd2dea404fd72d Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 9 Feb 2024 16:13:42 -0600
Subject: [PATCH] [LLVM] Add `__builtin_readsteadycounter` intrinsic and
buiiltin
S
jhuber6 wrote:
> Add to release notes?
Done
https://github.com/llvm/llvm-project/pull/81331
___
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/81331
___
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.
Looks fine.
https://github.com/llvm/llvm-project/pull/81693
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 commented:
This makes sense overall, though it's very complicated. Generally we just need
to make sure these things are private to one group of files. There's a lot more
to parse here compared to the `linker-wrapper`.
Do any of these tests check when called with `-r`
Author: Joseph Huber
Date: 2024-02-14T22:11:21-06:00
New Revision: fa9e297b8b63dacb962d99814e698658ad71f946
URL:
https://github.com/llvm/llvm-project/commit/fa9e297b8b63dacb962d99814e698658ad71f946
DIFF:
https://github.com/llvm/llvm-project/commit/fa9e297b8b63dacb962d99814e698658ad71f946.diff
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/81921
Summary:
This is a massive patch because it reworks the entire build and
everything that depends on it. This is not split up because various bots
would fail otherwise. I will attempt to describe the necessary chan
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81921
>From 5fdaa384ebc962429950b79098dee0581c74f4f3 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 13 Feb 2024 21:08:02 -0600
Subject: [PATCH] [libc] Rework the GPU build to be a regular target
Summary:
This
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/81921
___
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/81921
>From 613402be5f027c7f5494513772d0f17dd046a3e8 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 13 Feb 2024 21:08:02 -0600
Subject: [PATCH] [libc] Rework the GPU build to be a regular target
Summary:
This
@@ -533,15 +542,14 @@ endfunction(add_integration_test)
set(LIBC_HERMETIC_TEST_COMPILE_OPTIONS ${LIBC_COMPILE_OPTIONS_DEFAULT}
jhuber6 wrote:
Yeah there's a lot of logic that's moved and broken after rebasing. Trying to
figure out what's changed.
https://githu
@@ -1,12 +1,9 @@
set(libc_archive_targets "")
+ list(APPEND added_archive_targets ${archive_1})
jhuber6 wrote:
Don't know how that got there, I'll fix it.
https://github.com/llvm/llvm-project/pull/81921
___
cfe-commi
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81921
>From caf0ee274f353b6adb23c455121ec2102c260de0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 13 Feb 2024 21:08:02 -0600
Subject: [PATCH] [libc] Rework the GPU build to be a regular target
Summary:
This
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81921
>From d0f782f4db249f6be08dba5060ee403974c95fdf Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 13 Feb 2024 21:08:02 -0600
Subject: [PATCH] [libc] Rework the GPU build to be a regular target
Summary:
This
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81921
>From 3c4a7ea70941fbf3c8a47c0715423ae38cc25a68 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 13 Feb 2024 21:08:02 -0600
Subject: [PATCH] [libc] Rework the GPU build to be a regular target
Summary:
This
jhuber6 wrote:
ping
https://github.com/llvm/llvm-project/pull/80460
___
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/82004
Summary:
The original discussion in https://reviews.llvm.org/D118493 was that
`clang` should not be adding `-rpath` implicitly for toolchains. The
main motivation behind that change was the 'Fedora' toolchain
disa
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/82004
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
jhuber6 wrote:
> I don't think a CMake option is the right way to go here. For example, I
> doubt we would actually use this CMake option in Fedora if this patch is
> committed.
Does Fedora only use default configurations when building its packages?
> Does gcc use rpath for libgomp?
That's i
jhuber6 wrote:
> > Does Fedora only use default configurations when building its packages?
>
> We try to stick to the defaults as much as possible. Having an implicit rpath
> by default causes issues when building other RPMs with clang, and typically,
> if we need to change something in order
jhuber6 wrote:
> > We could make this logic more complicated by checking the system
> > automatically `execute_command(lsb_release)` or something.
>
> I think this is too complicated and fragile. If we want to do something
> specifically to support the distro use case, I think we should do thi
jhuber6 wrote:
> > I believe right now the `rtlib-rpath` points to the path
> > `${CLANG_BINARY}../lib/${HOST_TRIPLE}/`. I think it's definitely reasonable
> > to not put this on system libraries if that's a solution, since we can
> > generally assume it's a global installation and already cov
@@ -135,86 +147,20 @@ function(_get_common_test_compile_options output_var
flags)
# list(APPEND compile_options "-Wglobal-constructors")
# endif()
endif()
- if (LIBC_TARGET_ARCHITECTURE_IS_GPU)
-# TODO: Set these flags
-# list(APPEND compile_options "-nogp
@@ -135,86 +147,20 @@ function(_get_common_test_compile_options output_var
flags)
# list(APPEND compile_options "-Wglobal-constructors")
# endif()
endif()
- if (LIBC_TARGET_ARCHITECTURE_IS_GPU)
-# TODO: Set these flags
-# list(APPEND compile_options "-nogp
jhuber6 wrote:
> Could we have the upstream default be to install a clang.cfg file in bin/
> which has -fimplicit-openmp-rpath (or whatever the hoption is)?
Configuration files as far as I'm aware can't do toolchain / language specific
stuff, so it's a little weaker than being able to just res
@@ -2067,6 +2067,10 @@ Constant *ConstantExpr::getBitCast(Constant *C, Type
*DstTy,
Constant *ConstantExpr::getAddrSpaceCast(Constant *C, Type *DstTy,
bool OnlyIfReduced) {
+ // Skip cast if types are identical
jhuber
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81921
>From c4758c8663307708e5ac653a8692e595f4b1f4cc Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 13 Feb 2024 21:08:02 -0600
Subject: [PATCH] [libc] Rework the GPU build to be a regular target
Summary:
This
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/81921
>From 63e4205a9f5cc3ea8a4ce0730b01d78b6c9bde42 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 13 Feb 2024 21:08:02 -0600
Subject: [PATCH] [libc] Rework the GPU build to be a regular target
Summary:
This
301 - 400 of 1001 matches
Mail list logo
