Skip to content

[SYCL] Disable dead arg elimination for free function kernels #19776

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 27 commits into
base: sycl
Choose a base branch
from

Conversation

lbushi25
Copy link
Contributor

@lbushi25 lbushi25 commented Aug 12, 2025

This PR disables dead argument elimination for free function kernels. When using a free function kernel, the user sets the arguments manually using handler::set_arg but if certain arguments are optimized away in case they are not used, the implementation needs to be aware of this and remove the relevant set_arg calls. Instead, its much more feasible to just disable dead arg elimination in this case.

Copy link
Contributor

@AlexeySachkov AlexeySachkov left a comment

Choose a reason for hiding this comment

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

We need a LIT test for the change, see llvm/test/Transforms/DeadArgElim/sycl-kernels.ll for an example of existing test

@aelovikov-intel
Copy link
Contributor

I've removed reference to the internal bug report from the PR's description. That's not how upstream development should be done.

That said, the rest of the description was great and provides enough context for the change, so no additional actions needed.

@aelovikov-intel
Copy link
Contributor

Something is wrong with codeownership. I'd expect llvm to be owned by @intel/dpcpp-tools-reviewers , not by @intel/llvm-reviewers-runtime .

@lbushi25 lbushi25 requested a review from a team as a code owner August 13, 2025 18:48
@@ -93,18 +93,6 @@ void F<float>(int X) {
volatile float Y = static_cast<float>(X);
}

template <typename... Args>
Copy link
Contributor Author

@lbushi25 lbushi25 Aug 18, 2025

Choose a reason for hiding this comment

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

Variadic arguments are not allowed in free function kernels as per the spec here.
This case had been passing until now for some random reason, but disabling dead argument elimination causes it to fail.
It's illegal though, so might as well save a headache and remove it entirely.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was referring to line 99. I put the note on line 96 since its the start of the deleted section.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was referring to line 99. I put the note on line 96 since its the start of the deleted section.

Just to err on the safe side, I'm tagging @gmlueck. In the section of the spec that I have linked in my first comment in this thread, is the term "variadic argument" referring to the construct used in line 99 of this test that I've deleted or is it referring to some other construct?

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with @aelovikov-intel. The code on line 96 is not a function with variadic arguments. It is a function template with a parameter pack. When the template is instantiated, there is a fixed number of template arguments (defined by this particular instantiation), and therefore the instantiated function has a fixed number of arguments.

Such a function is expected to be a legal free function kernel. If it does not work, we should investigate why.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I see. There is already a tracker for this issue. In the meantime, to get this merged, I'm commenting out only this test case and adding a TODO to uncomment it once the tracker is solved. It's of course less than ideal to reduce test coverage but given that its important to have this change for free function kernels and the fact that the bug is exposed by this PR rather than caused by it, I think it's an acceptable compromise in light of the approaching deadline. Also tagging @AlexeySachkov for awareness.

@lbushi25
Copy link
Contributor Author

Re-requested review since this is high priority in the context of the next release.

Comment on lines +176 to +179
// Variadic template functions do not work with free function kernels. See
// CMPLRLLVM-69528.
// TODO: Uncomment the following line once the tracker is resolved.
// test_func<variadic_templated<double>, double>();
Copy link
Contributor

Choose a reason for hiding this comment

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

I'll leave review of this to @AlexeySachkov.

Copy link
Contributor

Choose a reason for hiding this comment

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

Is it a regression from this patch, or is it something previously known?

Copy link
Contributor Author

@lbushi25 lbushi25 Aug 21, 2025

Choose a reason for hiding this comment

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

Is it a regression from this patch, or is it something previously known?

I believe it's previously known. The failure described by the tracker has been happening since the test was created, it just wasn't caught by pre-commit since it only manifests with optimizations disabled.

Comment on lines +176 to +179
// Variadic template functions do not work with free function kernels. See
// CMPLRLLVM-69528.
// TODO: Uncomment the following line once the tracker is resolved.
// test_func<variadic_templated<double>, double>();
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it a regression from this patch, or is it something previously known?

Co-authored-by: Alexey Sachkov <[email protected]>
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.

5 participants