https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 859f6a7fce9503275ad7eb39512dc5833a11bb07 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Jun 2024 15:14:52 -0500
Subject: [PATCH] [Clang] Introduce 'clang-nvlink-wrappaer' to work around
'nvlink'
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 849c8dab14c9332081a8c6331c9ca0c234793393 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Jun 2024 15:14:52 -0500
Subject: [PATCH] [Clang] Introduce 'clang-nvlink-wrappaer' to work around
'nvlink'
jhuber6 wrote:
Re-did it and tested it against `libc` in
https://github.com/llvm/llvm-project/pull/96972 so it will have a CI running it
one that lands. it works for other cases I've tested, but let me know if
something else should be added.
https://github.com/llvm/llvm-project/pull/96561
__
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/96561
Summary:
The `clang-nvlink-wrapper` is a utility that I removed awhile back
during the transition to the new driver. This patch adds back in a new,
upgraded version that does LTO + archive linking. It's not an eas
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: Joseph Huber (jhuber6)
Changes
Summary:
The `clang-nvlink-wrapper` is a utility that I removed awhile back
during the transition to the new driver. This patch adds back in a new,
upgraded version that does LTO + archive linking. It's
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Joseph Huber (jhuber6)
Changes
Summary:
The `clang-nvlink-wrapper` is a utility that I removed awhile back
during the transition to the new driver. This patch adds back in a new,
upgraded version that does LTO + archive linking. It's not an
https://github.com/jhuber6 edited
https://github.com/llvm/llvm-project/pull/96561
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 8a52becd358abb2c96ca150db501d58c40b5250b Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Jun 2024 15:14:52 -0500
Subject: [PATCH] [Clang] Introduce 'clang-nvlink-wrappaer' to work around
'nvlink'
jlebar wrote:
@Artem-B asked me to review nvptx patches while he's OOO, but this one is
pretty far outside my depth. Are you OK waiting until he's back? I don't know
exactly when that will be, but based on his IMs to me, he should be back early
July.
https://github.com/llvm/llvm-project/pul
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 5edeeb9816fa5909f27a781f6e7213dd02ccdfa0 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Jun 2024 15:14:52 -0500
Subject: [PATCH] [Clang] Introduce 'clang-nvlink-wrappaer' to work around
'nvlink'
jhuber6 wrote:
> @Artem-B asked me to review nvptx patches while he's OOO, but this one is
> pretty far outside my depth. Are you OK waiting until he's back? I don't know
> exactly when that will be, but based on his IMs to me, he should be back
> early July.
No problem, I knew that it would
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/96561
>From 6c70e542bbb355160b833ede6f86be0366953b88 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Mon, 24 Jun 2024 15:14:52 -0500
Subject: [PATCH] [Clang] Introduce 'clang-nvlink-wrappaer' to work around
'nvlink'
jhuber6 wrote:
@MaskRay So, I think my symbol resolution is (unsurprisingly) subtly broken. Is
there a canonical way to handle this? I first thought that we could simply
perform the symbol resolutions as normal for every file, but keep track of
which symbols were "lazy". However, I couldn't fi
13 matches
Mail list logo
