https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/159451
>From d79f0b2479258004fe3770b7d14486891226452f Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 21 Jul 2025 14:38:03 -0500
Subject: [PATCH] [LLVM] Update CUDA ELF flags for their new ABI (#149534)
Summary
https://github.com/jhuber6 milestoned
https://github.com/llvm/llvm-project/pull/159451
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/159451
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/159451
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/157773
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -656,6 +671,49 @@ Error olCreateQueue_impl(ol_device_handle_t Device,
ol_queue_handle_t *Queue) {
return Error::success();
}
+Error olGetMemInfoImplDetail(ol_platform_handle_t Platform, const void *Ptr,
+ ol_mem_info_t PropName, size_t PropSiz
@@ -614,6 +614,21 @@ TargetAllocTy convertOlToPluginAllocTy(ol_alloc_type_t
Type) {
}
}
+ol_alloc_type_t convertPluginToOlAllocTy(TargetAllocTy Type) {
+ switch (Type) {
+ case TARGET_ALLOC_DEVICE:
+return OL_ALLOC_TYPE_DEVICE;
+ case TARGET_ALLOC_HOST:
+return O
Author: Joseph Huber
Date: 2025-08-19T11:19:35-05:00
New Revision: e2777af84b5acce6f95d71653b817011e6f57a02
URL:
https://github.com/llvm/llvm-project/commit/e2777af84b5acce6f95d71653b817011e6f57a02
DIFF:
https://github.com/llvm/llvm-project/commit/e2777af84b5acce6f95d71653b817011e6f57a02.diff
jhuber6 wrote:
@frasercrmck Did we get `libclc` fully working from the runtimes configuration?
https://github.com/llvm/llvm-project/pull/152302
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailm
jhuber6 wrote:
I would really like https://github.com/llvm/llvm-project/issues/98897 to be
discussed because we merge this. As it stands it makes builds take an
unreasonably long amount of time.
https://github.com/llvm/llvm-project/pull/152302
___
ll
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/150170
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
jhuber6 wrote:
If it destroys the queue it could be like 'Finalize' or something.
https://github.com/llvm/llvm-project/pull/150036
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/l
https://github.com/jhuber6 approved this pull request.
Simple enough
https://github.com/llvm/llvm-project/pull/150036
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-co
jhuber6 wrote:
This seems like something we should discuss at one of the weekly meetings,
since it has pretty large implications for what this library is supposed to do.
https://github.com/llvm/llvm-project/pull/148648
___
llvm-branch-commits mailing
jhuber6 wrote:
> @jhuber6 I'm looking at implementing a version of
> [urProgramLink](https://oneapi-src.github.io/unified-runtime/core/api.html#urprogramlink)
> for liboffload, which is used by SYCL.
>
> More generally though, linking is very backend dependant, and liboffload
> already has lo
https://github.com/jhuber6 commented:
I'm kind of iffy here, I'm not sure if it's the runtime's job to be a linker.
The `createProgram` interface already should handle 'JIT' compilation by
detecting magics bits for LLVM-IR, ELF, PTX, or SPIR-V or whatever, but it's
expected that the user provi
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/147962
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
jhuber6 wrote:
> @jhuber6 Given that this interface matches the interface of other handles,
> any change to how it fundamentally works should probably involve updating all
> other getInfo queries. If we do decide to replace the Size variants, I think
> that should be done as a separate task th
https://github.com/jhuber6 commented:
I would prefer that we do this like HSA does and have
`HSA_EXECUTABLE_SYMBOL_INFO_NAME_LENGTH` as a separate info that you can query
first and then use as a pointer for `HSA_EXECUTABLE_SYMBOL_INFO_NAME`.
https://github.com/llvm/llvm-project/pull/147962
___
https://github.com/jhuber6 approved this pull request.
I'm wondering if we could just make it `getSymbol` instead of `getKernel`. We
need to disambiguate for the underlying runtime calls (AMDGPU needs `.kd` and
CUDA uses a different one) but that should be easily doable with a quick lookup
in
jhuber6 wrote:
> @jhuber6 Some queries (such as name and vendor) return strings, binary data
> or arrays. This entry point allows the implementation to pre-allocate storage
> for them.
>
> It's also useful for offload users that want to create a generic "readInfo"
> function that allocates an
https://github.com/jhuber6 commented:
What do we use the `Size` variant for exactly? I figured that would just be
part of the query, most documentation will state how big the output variable
needs to be when using some of these enums.
https://github.com/llvm/llvm-project/pull/147962
_
https://github.com/jhuber6 commented:
Debating whether or not we should just have `olGetSymbol` and let the user
assume whether or not it's a kernel and let them use the info to verify if
they're unsure.
https://github.com/llvm/llvm-project/pull/147944
_
@@ -171,6 +186,12 @@ struct InfoTreeNode {
return It;
}
+ std::optional get(DeviceInfo Info) {
+if (DeviceInfoMap.count(Info))
+ return &(*Children)[DeviceInfoMap[Info]];
+return std::nullopt;
jhuber6 wrote:
```suggestion
return !Devic
@@ -133,17 +139,21 @@ struct InfoTreeNode {
// * The same key can appear multiple times
std::unique_ptr> Children;
+ std::map DeviceInfoMap;
jhuber6 wrote:
Do these need to be sorted? Otherwise a dense map is more efficient.
https://github.com/llvm/llvm
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/147225
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 approved this pull request.
Nice to see fewer of these used. We should be able to get rid of the
wavefrontsize ones if we use the builtin, and if Alex's WIP lands we can
replace the ISA checks with that.
https://github.com/llvm/llvm-project/pull/134805
__
jhuber6 wrote:
It is very important that this gets backported.
https://github.com/llvm/llvm-project/pull/126121
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
jhuber6 wrote:
> @jhuber6 Why do you want to back port this and what's the impact if we don't?
Sorry, https://github.com/llvm/llvm-project/pull/127703 is the actually
important one and I forget to cherry pick it, fixes a test and incorrect
behavior. Figured if I was backporting that I could me
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/127842
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 approved this pull request.
Approving my own patch feels like a conflict of interest.
https://github.com/llvm/llvm-project/pull/127704
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/127496
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/127099
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -106,8 +106,6 @@ enum class OffloadArch {
GFX90a,
GFX90c,
GFX9_4_GENERIC,
- GFX940,
- GFX941,
jhuber6 wrote:
So `--offload-arch=gfx940` will be a hard error after working at least since
clang 16? That sounds very silly.
https://github.com/llvm/llv
https://github.com/jhuber6 approved this pull request.
Okay, so I guess we can delete these because the cards that corresponded to
these were never fully released as I understand it.
https://github.com/llvm/llvm-project/pull/126762
___
llvm-branch-com
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/126762
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -106,8 +106,6 @@ enum class OffloadArch {
GFX90a,
GFX90c,
GFX9_4_GENERIC,
- GFX940,
- GFX941,
jhuber6 wrote:
Seems bizarre to just fully remove support when we still accept things like
`gfx600` to this day. As far as I understand, these are basical
jhuber6 wrote:
> @jhuber6 Can you take a look at these test failures.
Looks green now.
https://github.com/llvm/llvm-project/pull/125912
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/list
jhuber6 wrote:
Should just be the two commits, it just unfortunately took the name of the
latest one. I would've squashed them if I knew how.
https://github.com/llvm/llvm-project/pull/125912
___
llvm-branch-commits mailing list
llvm-branch-commits@lis
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/126193
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -51,7 +51,8 @@ set(LIBC_KERNEL_HEADERS "/usr/include" CACHE STRING "Path to
Linux kernel header
# Defining a global namespace to enclose all libc functions.
set(default_namespace "__llvm_libc")
if(LLVM_VERSION_MAJOR)
- set(default_namespace
"__llvm_libc_${LLVM_VERSION_MAJ
https://github.com/jhuber6 commented:
Is this a backport? I don't see one for the `main` branch. Normally you land it
on main and follow
https://llvm.org/docs/GitHub.html#backporting-fixes-to-the-release-branches for
the backport.
https://github.com/llvm/llvm-project/pull/126193
_
=?utf-8?q?Micha=C5=82_G=C3=B3rny?=
Message-ID:
In-Reply-To:
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/125498
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/124417
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 approved this pull request.
Straightforward renaming and more consistent with the clang runtimes.
https://github.com/llvm/llvm-project/pull/122341
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https:
@@ -1,47 +1,34 @@
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
-add_library(FortranEvaluateTesting
jhuber6 wrote:
Does anyone use the omp offload build? I'm hoping to make that unnecessary once
we have the flang-rt build working.
https://git
jhuber6 wrote:
Somewhere for the linker wrapper I just checked if the triple was recognized,
you could probably just take strings after the `-` until it stops working.
https://github.com/llvm/llvm-project/pull/122629
___
llvm-branch-commits mailing li
https://github.com/jhuber6 approved this pull request.
Seems reasonable to me
https://github.com/llvm/llvm-project/pull/122069
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-
@@ -0,0 +1,232 @@
+#===-- CMakeLists.txt
--===#
+#
+# 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: Apache-
jhuber6 wrote:
> 1. Approved
>
> 2. Wrt OpenCL ... I hope legalization didn't get broken, but in the
> OpenCL flow, pryntf should lower to ... `printf()`, which the compiler will
> handle. Or at least that's my recollection of how that goes from staring at
> the AMDGPU backend ~a year ago
jhuber6 wrote:
> > Also, I noticed that both linux and windows builds fail to generate some
> > subcommands apparently (but this doesn't seem to cause an explicit error):
> > ```
> > [70/72] Generating $PREFIX/compile_commands.json
> > Failed to parse {json_file}: {e}
> > ```
> >
> >
> >
=?utf-8?q?Micha=C5=82_G=C3=B3rny?= ,
=?utf-8?q?Micha=C5=82_G=C3=B3rny?= ,
=?utf-8?q?Micha=C5=82_G=C3=B3rny?= ,
=?utf-8?q?Micha=C5=82_G=C3=B3rny?= ,
=?utf-8?q?Micha=C5=82_G=C3=B3rny?=
Message-ID:
In-Reply-To:
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-p
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/117422
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 approved this pull request.
LG
https://github.com/llvm/llvm-project/pull/117411
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -150,12 +150,18 @@ if ("flang" IN_LIST LLVM_ENABLE_PROJECTS)
endif()
endif()
+if ("flang-rt" IN_LIST LLVM_ENABLE_RUNTIMES)
+ if (NOT "flang" IN_LIST LLVM_ENABLE_PROJECTS)
+message(FATAL_ERROR "Flang is not enabled, but is required for the
Flang-RT runtime")
+ endif
jhuber6 wrote:
> > This patch doesn't apply cleanly for me
>
> That's because it's a series of patches (see OP), so you have to apply them
> all in order (or simply check out the branch that represents this PR)
I thought that's what happens by default when you use
https://patch-diff.githubuse
jhuber6 wrote:
This patch doesn't apply cleanly for me
https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 commented:
Does anyone know why this patch keeps failing the libc++ tests? Seems related
to something in `libc` for some reason. If we could get the CI green I'd be
happy to say it's good enough for now.
https://github.com/llvm/llvm-project/pull/110217
__
jhuber6 wrote:
> > Overall I think the patch is fine pending some naming nits, my one concern
> > is the `-U__GLIBCXX` stuff, because undefining internal vars seems really
> > sketchy. Do we use `-nostdlib++` to make sure we don't link the C++ library?
>
> There is a
> [test](https://github.c
jhuber6 wrote:
Overall I think the patch is fine pending some naming nits, my one concern is
the `-U__GLIBCXX` stuff, because undefining internal vars seems really sketchy.
Do we use `-nostdlib++` to make sure we don't link the C++ library?
https://github.com/llvm/llvm-project/pull/110217
@@ -0,0 +1,165 @@
+#===-- CMakeLists.txt
--===#
+#
+# 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: Apache-
@@ -171,145 +76,88 @@ set(sources
unit-map.cpp
unit.cpp
utf.cpp
- ${FORTRAN_MODULE_OBJECTS}
)
-include(AddFlangOffloadRuntime)
-
-# List of files that are buildable for all devices.
-set(supported_files
- ISO_Fortran_binding.cpp
- allocatable.cpp
- allocator-regist
@@ -171,145 +76,88 @@ set(sources
unit-map.cpp
unit.cpp
utf.cpp
- ${FORTRAN_MODULE_OBJECTS}
)
-include(AddFlangOffloadRuntime)
-
-# List of files that are buildable for all devices.
-set(supported_files
- ISO_Fortran_binding.cpp
- allocatable.cpp
- allocator-regist
@@ -171,145 +76,88 @@ set(sources
unit-map.cpp
unit.cpp
utf.cpp
- ${FORTRAN_MODULE_OBJECTS}
)
-include(AddFlangOffloadRuntime)
-
-# List of files that are buildable for all devices.
-set(supported_files
- ISO_Fortran_binding.cpp
- allocatable.cpp
- allocator-regist
@@ -0,0 +1,165 @@
+#===-- CMakeLists.txt
--===#
+#
+# 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: Apache-
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/110217
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -270,13 +271,15 @@ function(runtime_default_target)
-DLLVM_BUILD_TOOLS=${LLVM_BUILD_TOOLS}
-DCMAKE_C_COMPILER_WORKS=ON
-DCMAKE_CXX_COMPILER_WORKS=ON
+
@@ -0,0 +1,165 @@
+#===-- CMakeLists.txt
--===#
+#
+# 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: Apache-
@@ -221,6 +230,9 @@ function(llvm_ExternalProject_Add name source_dir)
-DCMAKE_ASM_COMPILER=${LLVM_RUNTIME_OUTPUT_INTDIR}/clang${CMAKE_EXECUTABLE_SUFFIX})
endif()
endif()
+if(FLANG_IN_TOOLCHAIN)
+ list(APPEND compiler_args
-DCMAKE_
https://github.com/jhuber6 approved this pull request.
Makes sense, thanks again.
https://github.com/llvm/llvm-project/pull/114113
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/l
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/113038
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/111652
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 approved this pull request.
Thanks
https://github.com/llvm/llvm-project/pull/106439
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/100216
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
jhuber6 wrote:
So, in the "bad" case, it's finding the LLVMConfig.cmake I would expect. The
"good" case is picking up the wrong one, but it somehow works? In both cases it
reports that LLVM was found, but the one in-tree doesn't work for some reason.
Sorry for all the questions, I'm not able t
jhuber6 wrote:
> For reasons I don't understand, cmake (version 3.22.1, default on Ubuntu
> 22.04.4) is not producing debug output for the find_package call for LLVM if
> I use `cmake --debug-find`. It does produce output for other packages.
>
> Resorting to strace -efile:
>
> Good:
>
> ```
jhuber6 wrote:
>
> It appears that in the bad case, `LLVM_CMAKE_DIR` during the `find_package`
> is set to `/home/ubuntu/llvm-project/llvm/cmake/modules`. In the good case,
> it's set to `/home/ubuntu/bld`.
The latter is what it's supposed to do, I would think? When doing a runtimes
build it
jhuber6 wrote:
Do you any clue why this is broken? `LLVM_CMAKE_DIR` should be innocuous
enough, so if it's causing failures then there's probably a separate issue.
https://github.com/llvm/llvm-project/pull/102475
___
llvm-branch-commits mailing list
l
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/101887
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 approved this pull request.
https://github.com/llvm/llvm-project/pull/100291
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/100291
>From c3dfd23fd6bb167eb6be49a24aef14a0f5621d8d Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 23 Jul 2024 21:35:09 -0500
Subject: [PATCH 1/2] [libc] Fix leftover debug commandline argument
Summary:
Fixe
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/100291
>From c3dfd23fd6bb167eb6be49a24aef14a0f5621d8d Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 23 Jul 2024 21:35:09 -0500
Subject: [PATCH 1/2] [libc] Fix leftover debug commandline argument
Summary:
Fixe
@@ -29,7 +29,7 @@ to learn about the defaults for your platform and target.
- ``LIBC_CONF_ENABLE_STRONG_STACK_PROTECTOR``: Enable
-fstack-protector-strong to defend against stack smashing attack.
- ``LIBC_CONF_KEEP_FRAME_POINTER``: Keep frame pointer in functions for
b
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/100216
>From d7f99606094fc1feb41b50de0b0eb6d07460 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 23 Jul 2024 14:41:57 -0500
Subject: [PATCH 1/5] [Clang] Correctly forward `--cuda-path` to the nvlink
wrappe
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/100216
>From d7f99606094fc1feb41b50de0b0eb6d07460 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 23 Jul 2024 14:41:57 -0500
Subject: [PATCH 1/4] [Clang] Correctly forward `--cuda-path` to the nvlink
wrappe
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/100216
>From d7f99606094fc1feb41b50de0b0eb6d07460 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 23 Jul 2024 14:41:57 -0500
Subject: [PATCH 1/3] [Clang] Correctly forward `--cuda-path` to the nvlink
wrappe
@@ -23,14 +22,14 @@
// RUN: %t/host-x86_64-unknown-linux-gnu.s
// Check plugin, -passes, and no remarks.
-// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+// RUN: clang-linker-wrapper -o a.out --embed-bitcode --dry-run \
// RUN: --linker-path=/usr/bin/true %t/
@@ -23,14 +22,14 @@
// RUN: %t/host-x86_64-unknown-linux-gnu.s
// Check plugin, -passes, and no remarks.
-// RUN: clang-linker-wrapper -o a.out --embed-bitcode \
+// RUN: clang-linker-wrapper -o a.out --embed-bitcode --dry-run \
jhuber6 wrote:
```suggesti
@@ -43,7 +42,7 @@
// RUN: -check-prefixes=YML %s
// Check handling of bad plugin.
-// RUN: not clang-linker-wrapper \
+// RUN: not clang-linker-wrapper --dry-run \
jhuber6 wrote:
```suggestion
// RUN: not clang-linker-wrapper \
```
https://github.com/llv
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/100216
>From d7f99606094fc1feb41b50de0b0eb6d07460 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Tue, 23 Jul 2024 14:41:57 -0500
Subject: [PATCH 1/2] [Clang] Correctly forward `--cuda-path` to the nvlink
wrappe
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/100216
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
@@ -1,9 +1,5 @@
// Check various clang-linker-wrapper pass options after -offload-opt.
jhuber6 wrote:
```suggestion
// REQUIRES: llvm-plugins, llvm-examples
// REQUIRES: x86-registered-target
// REQUIRES: amdgpu-registered-target
```
https://github.com/llvm/l
jhuber6 wrote:
This should be merged
https://github.com/llvm/llvm-project/pull/100174
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
https://github.com/jhuber6 closed
https://github.com/llvm/llvm-project/pull/95484
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
jhuber6 wrote:
I merged my patch, I think the window to backport to 18.x is passed so you'll
need to use the main branch for now. Thanks for bringing this to my attention.
https://github.com/llvm/llvm-project/pull/95484
___
llvm-branch-commits mailing
jhuber6 wrote:
Made https://github.com/llvm/llvm-project/pull/95769, don't know if the window
for the 18.x window is still open for a back port.
https://github.com/llvm/llvm-project/pull/95484
___
llvm-branch-commits mailing list
llvm-branch-commits@l
jhuber6 wrote:
> This doesn't make sense, the ROCm packages may be just badly made by AMD.
>
> When I temporarily remove `/usr/include/hsa` without uninstalling
> `libhsa-runtime-dev` **AND** while using
> `-DLIBOMPTARGET_FORCE_DLOPEN_LIBHSA=ON`, I can build LLVM18 without patch.
>
> With `-D
jhuber6 wrote:
> The `openmp/libomptarget/plugins-nextgen/amdgpu/src/rtl.cpp` file requires
> the `HSA_AMD_AGENT_INFO_TIMESTAMP_FREQUENCY` symbol.
>
> This symbol is expected to be provided by
> `openmp/libomptarget/plugins-nextgen/amdgpu/dynamic_hsa/hsa_ext_amd.h`, not
> by third-party exter
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/95484
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
1 - 100 of 112 matches
Mail list logo
