Skip to content

[SYCL] Disable printing in SYCL headers when compiling for device#22236

Open
vmustya wants to merge 2 commits into
intel:syclfrom
vmustya:sycl-device-disable-ostream
Open

[SYCL] Disable printing in SYCL headers when compiling for device#22236
vmustya wants to merge 2 commits into
intel:syclfrom
vmustya:sycl-device-disable-ostream

Conversation

@vmustya

@vmustya vmustya commented Jun 5, 2026

Copy link
Copy Markdown
Contributor

The SYCL device/JIT environment don't support printing, so disable it in
the SYCL headers when compiling for device. This is needed to avoid
compilation errors when the headers are included in device code.

The SYCL device/JIT environment don't support printing, so disable it in
the SYCL headers when compiling for device. This is needed to avoid
compilation errors when the headers are included in device code.
@vmustya vmustya requested a review from a team as a code owner June 5, 2026 16:57
@vmustya vmustya requested a review from slawekptak June 5, 2026 16:57

@sarnex sarnex 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.

adding others to review this on content, not qualified myself

inline namespace _V1 {

inline std::ostream &operator<<(std::ostream &Out, backend be) {
#if !defined(__SYCL_DEVICE_ONLY__)

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.

Can we add a test, either e2e or lit, to lock this down? Otherwise someone could break it and we'd have no idea for a while

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.

I have really no ideas how to add tests for these particular changes.

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.

Maybe dump the device IR and look for string consts? Maybe others have a better idea

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.

A lot of what you are doing in this I implemented on #22047 and move those functions at the src runtime.


// to output exceptions caught in ~destructors
#ifndef NDEBUG
#if !defined(NDEBUG) && !defined(__SYCL_DEVICE_ONLY__)

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 looks like a fixed function signature. Can we have a runtime function that has some signature like:

report_exception_error(std::string_view, const char*);

If device compilation ever reaches here (which it shouldn't you should get a link error, and you can verify this, in the tests).

Comment on lines 59 to +71
@@ -67,6 +68,7 @@ inline void defaultAsyncHandler(exception_list Exceptions) {
}
}
std::cerr << std::endl;
#endif // !defined(__SYCL_DEVICE_ONLY__)

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.

Move the entire function into the runtime, leave declaration and add __SYCL_EXPORT.

Comment on lines 232 to 233
std::cout << "parallel_for range adjusted at dim " << Dim << " from "
<< RoundedRange[Dim] << " to " << Value << std::endl;

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.

Extend: sycl/source/detail/range_rounding.cpp with a reportAdustedRange() function that prints out the same message.

@koparasy koparasy 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.

To avoid macros overall I think these functions should move in the runtime in the first place. Longer term these headers will not need to pull in iostream (even when doing host compilation). I have some suggestions on how to get there.

I believe if you do it this way you can have "negative" tests, have device only codes that directly call these functions, which should result into linkage errors. As there are no definitions of the suggested functions.

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