Skip to content

[SYCL][Driver] Warn when total Device code-size causes relocation errors - #23523

Open
bviyer wants to merge 8 commits into
syclfrom
bviyer-make-better-warning
Open

bviyer wants to merge 8 commits into
syclfrom
bviyer-make-better-warning

Conversation

@bviyer

@bviyer bviyer commented Oct 16, 2026

Copy link
Copy Markdown
Contributor

Large device code can push the 32-bit PC relative relocations past their 2GB reach. this causes host linker to fail with errors such as "relocation truncated to fit." In this PR, such cases are dignosed at linked time via -Wlarge-device-kernel flag and providing user suggestion to use the flink-huge-device-code as a fix.

@bviyer
bviyer requested review from a team as code owners October 16, 2026 20:04
Comment thread clang/include/clang/Basic/DiagnosticDriverKinds.td Outdated
Comment thread clang/include/clang/Basic/DiagnosticDriverKinds.td Outdated
Comment thread clang/lib/Driver/ToolChains/Gnu.cpp Outdated
Comment thread clang/lib/Driver/ToolChains/Gnu.cpp
Comment thread clang/test/Driver/sycl-huge-device-code-warning.cpp Outdated
Comment thread clang/lib/Driver/ToolChains/Gnu.cpp Outdated
Comment thread clang/test/Driver/sycl-huge-device-code-warning.cpp
Comment thread clang/lib/Driver/ToolChains/Gnu.cpp Outdated

@elizabethandrews elizabethandrews left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is primarily a Driver Change with just a warning group declared in FE. I defer to @mdtoguchi for review. I agree that the current proposed warning is too verbose.

@mdtoguchi mdtoguchi changed the title [SYCL] Warn when total Device code-size causes relocation errors [SYCL][Driver] Warn when total Device code-size causes relocation errors Oct 22, 2026
Comment thread clang/test/Driver/sycl-huge-device-code-warning.cpp
@bviyer
bviyer requested a review from mdtoguchi October 22, 2026 17:23
Comment thread clang/lib/Driver/ToolChains/Gnu.cpp Outdated
@bviyer
bviyer requested a review from mdtoguchi October 26, 2026 20:36

for (const InputInfo &II : Inputs)
if (II.isFilename() &&
isa_and_nonnull<OffloadWrapperJobAction>(II.getAction())) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is good for the old offload model. We should also look into a solution for the new model - I would expect that to be more in the clang-linker-wrapper space.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we do that in a separate PR?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, this can be done in a separate PR.

Comment thread clang/lib/Driver/ToolChains/Gnu.cpp Outdated
static constexpr uint64_t HugeDeviceCodeWarnThreshold = 1ull << 30; // 1GiB

// Sums the size of only those link inputs that carry wrapped device code,
// i.e. skips host objects, static archives, and other linker inputs that

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the comment on static archives isn't true - as static archives should be queried as well, as they can be 'fat archives'. But that query happens in a different area so the device objects from any static archives should already be processed along with the other device binaries.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

Comment thread clang/include/clang/Basic/DiagnosticDriverKinds.td Outdated
"clang LLVM compiler", InMemoryFileSystem);
TheDriver.setCheckInputsExist(false);
std::unique_ptr<Compilation> C(TheDriver.BuildCompilation(
{"/usr/bin/clang++", "-fsycl", "-nostdlib", "foo.cpp", "-o", "foo.out"}));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably don't want the link step to occur when the warning is triggered. Adding -Werror=large-device-kernel will prevent it from running the link.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.


// RUN: rm -f %t-big.o

// NO-WARN-NOT: total link input size

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing tests that check that -flink-huge-device-code and -Wno-large-device-kernel prevent the warning from being emitted.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may have commented here to add these checks - but given that the originating objects don't have any device code in the first place - the additional tests aren't going to be doing anything here and will just be spinning compilation time on large inputs.

// RUN: %python -c "open(r'%t-big.o', 'wb').truncate(1100000000)"
// RUN: %python -c "open(r'%t-small.o', 'wb').truncate(1000)"

// RUN: %clangxx -fsycl %t-big.o %t-small.o -o %t.out > %t-warn.log 2>&1 || true

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// RUN: %clangxx -fsycl %t-big.o %t-small.o -o %t.out > %t-warn.log 2>&1 || true
// RUN: %clangxx -fsycl %t-big.o %t-small.o -o %t.out > %t-warn.log 2>&1

No expectation for this command to fail is there? I don't think the || true is necessary.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@bviyer
bviyer requested a review from mdtoguchi October 27, 2026 19:52
Comment on lines +24 to +31
// RUN: %clangxx -fsycl -fuse-ld=/bin/true %t-big.o %t-small.o -o %t.out > %t-warn.log 2>&1
// RUN: FileCheck --check-prefix=NO-WARN --allow-empty %s < %t-warn.log

// RUN: %clangxx -fsycl -fuse-ld=/bin/true -flink-huge-device-code %t-big.o %t-small.o -o %t.out > %t-flink.log 2>&1
// RUN: FileCheck --check-prefix=NO-WARN --allow-empty %s < %t-flink.log

// RUN: %clangxx -fsycl -fuse-ld=/bin/true -Wno-large-device-kernel %t-big.o %t-small.o -o %t.out > %t-wno.log 2>&1
// RUN: FileCheck --check-prefix=NO-WARN --allow-empty %s < %t-wno.log

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would expect these tests to fail in the new offload model setting. Probably should add --no-offload-new-driver to these command lines.

Comment on lines +1008 to +1009
// short-circuit instead of actually invoking the (nonexistent, in this
// test) linker -- that's what we want, since the point here is just to

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment says that the linker is non-existent. Probably not a true statement. Should just say we don't want to invoke the linker.

Comment on lines +1097 to +1098
EXPECT_TRUE(DiagConsumer->Msgs.empty());
EXPECT_TRUE(DiagConsumer->Errors.empty());

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These will fail if any diagnostic is emitted. Probably should tighten this up to check for more of the specific diagnostic messaging (not) expected.

Comment on lines +1067 to +1068
EXPECT_TRUE(DiagConsumer->Msgs.empty());
EXPECT_TRUE(DiagConsumer->Errors.empty());

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as below in regards to tightening up the diagnostic to not be emitted.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants