[clang][SYCL] Disable address space optimization for kernel args by Fznamznon · Pull Request #21781 · intel/llvm

Fznamznon · 2026-04-15T14:00:27Z

For struct/class SYCL kernel arguments with pointer fields clang generated a new type with the same field types except all pointers have global address space instead of default. A parameter of new generated type appeared within kernel parameters. Then in kernel body some level of type punning was applied to reuse original AST without heavily modifying it in order to initialize kernel object with an argument of the generated type. This was implemented 5+ years back in order to achieve better performance. The current patch disables this optimization by default for two reasons:

We now believe that address space optimizations should be done by IGC
IGC is already capable of performing address space optimizations

This PR also introduces a cc1 option that allows to roll back to the old behavior in case there is performance regressions after this change.

Assisted-by: claude in test cases updating

For struct/class SYCL kernel agruments with pointer fields clang now generates a new type with the same field types except all pointers have global address space instead of default. A parameter of new generated type appears within kernel parameters. Then in kernel body some level of type punning is applied to reuse original AST without heavily modifying it in order to initialize kernel object with an argument of the generated type. This was implemented 5+ years back in order to achieve better performace. The current patch disables this optimization for two reasons: - We now believe that address space optimizations should be done by IGC - IGC is already capable of performing address space optimizations This PR also introduces a cc1 option that allows to roll back to the old behavior in case there is performace regressions after this change.

bader

LGTM.
Thanks!

elizabethandrews

Yay!

tahonermann

Looks great overall. I suggested one minor change to avoid any possible confusion regarding "glob" and "global" and a couple of questions regarding tests that don't perform both the GLOB-AS and GEN-AS checks.

tahonermann · 2026-04-21T17:12:45Z

+// RUN: %clang_cc1 -internal-isystem %S/Inputs -fsycl-is-device -triple spir64 \
+// RUN: -fsycl-force-glob-as-in-kernel-args -emit-llvm %s -o - | FileCheck %s --check-prefix=GLOB-AS


In -fsycl-force-glob-as-in-kernel-args mode, the CHECK lines won't be validated. Is that intentional/ok? That could lead to spurious matches.

No, that is not intentional. Great catch, thanks. Fixed in 1cf995d .

tahonermann · 2026-04-21T17:15:06Z

@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fno-sycl-force-inline-kernel-lambda -fsycl-is-device -internal-isystem %S/Inputs -triple spir64-unknown-unknown -disable-llvm-passes -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fno-sycl-force-inline-kernel-lambda -fsycl-is-device -internal-isystem %S/Inputs -triple spir64-unknown-unknown -disable-llvm-passes -emit-llvm -fsycl-force-glob-as-in-kernel-args %s -o - | FileCheck %s


Shouldn't this test be exercised in non -fsycl-force-glob-as-in-kernel-args mode as well?

This is done intentionally. The test is named generated-types-initialization.cpp and seems to be intended to check newly generated types that contain pointers with fixed address spaces. Since there is no generated types in non -fsycl-force-glob-as-in-kernel-args , the test doesn't make sense in this mode.

Ok, thanks, that makes sense.

tahonermann · 2026-04-21T17:21:20Z

      h.single_task<class Pointer>([=]() { return SimpleStructWithPtr.i; });
    });
-    // CHECK: FunctionDecl {{.*}}Pointer{{.*}} 'void (__generated_StructWithPtr) __attribute__((device_kernel))'
+    // CHECK: FunctionDecl {{.*}}Pointer{{.*}} 'void (StructWithPtr) __attribute__((device_kernel))'


What is the reason for not exercising this test both with and without -fsycl-force-glob-as-in-kernel-args?

The test seemed to be focused on accessor and other special types and decomposition mechanism. Since pointers don't trigger decomposition, I reduced PR size by not exercising non fsycl-force-glob-as-in-kernel-args mode. This seems to be covered well by other tests in this PR.

Ok, that makes sense. Thanks!

tahonermann · 2026-04-21T17:24:21Z

+def fsycl_force_glob_as_in_kernel_args : Flag<["-"], "fsycl-force-glob-as-in-kernel-args">,
+  HelpText<"Force global address space for USM pointers within SYCL kernel arguments">,
+  MarshallingInfoFlag<LangOpts<"SYCLForceGlobASInKernelArgs">>;



Given that the option name is already kind of long and that "glob" has alternative interpretations, I suggest we spell out global to avoid any confusion.

Suggested change

def fsycl_force_glob_as_in_kernel_args : Flag<["-"], "fsycl-force-glob-as-in-kernel-args">,

HelpText<"Force global address space for USM pointers within SYCL kernel arguments">,

MarshallingInfoFlag<LangOpts<"SYCLForceGlobASInKernelArgs">>;

def fsycl_force_global_as_in_kernel_args : Flag<["-"], "fsycl-force-global-as-in-kernel-args">,

HelpText<"Force global address space for USM pointers within SYCL kernel arguments">,

MarshallingInfoFlag<LangOpts<"SYCLForceGlobalASInKernelArgs">>;

No problem, renamed in 47ea2a6 with test fixes in d51534e .

Fznamznon · 2026-04-22T12:41:43Z

@tahonermann , thanks for the feedback, I replied to all comments.

tahonermann

Looks great, thanks @Fznamznon!

tahonermann · 2026-04-22T15:58:42Z

      h.single_task<class Pointer>([=]() { return SimpleStructWithPtr.i; });
    });
-    // CHECK: FunctionDecl {{.*}}Pointer{{.*}} 'void (__generated_StructWithPtr) __attribute__((device_kernel))'
+    // CHECK: FunctionDecl {{.*}}Pointer{{.*}} 'void (StructWithPtr) __attribute__((device_kernel))'


Ok, that makes sense. Thanks!

tahonermann · 2026-04-22T16:08:10Z

@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fno-sycl-force-inline-kernel-lambda -fsycl-is-device -internal-isystem %S/Inputs -triple spir64-unknown-unknown -disable-llvm-passes -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fno-sycl-force-inline-kernel-lambda -fsycl-is-device -internal-isystem %S/Inputs -triple spir64-unknown-unknown -disable-llvm-passes -emit-llvm -fsycl-force-glob-as-in-kernel-args %s -o - | FileCheck %s


Ok, thanks, that makes sense.

Fznamznon · 2026-04-23T08:32:25Z

@intel/llvm-gatekeepers , this is ready to merge.

Fznamznon requested a review from a team as a code owner April 15, 2026 14:00

Fznamznon requested a review from bader April 15, 2026 14:00

bader approved these changes Apr 15, 2026

View reviewed changes

elizabethandrews approved these changes Apr 16, 2026

View reviewed changes

tahonermann suggested changes Apr 21, 2026

View reviewed changes

Fznamznon added 4 commits April 22, 2026 04:23

Merge branch 'sycl' into disable-as-type-punning

27ff0e5

Check the CHECK checks

1cf995d

Rename the option

47ea2a6

Fix tests after option renaming

d51534e

Fznamznon requested a review from tahonermann April 22, 2026 12:41

tahonermann approved these changes Apr 22, 2026

View reviewed changes

KornevNikita merged commit 437f95c into intel:sycl Apr 23, 2026
36 of 37 checks passed

		// RUN: %clang_cc1 -internal-isystem %S/Inputs -fsycl-is-device -triple spir64 \
		// RUN: -fsycl-force-glob-as-in-kernel-args -emit-llvm %s -o - \| FileCheck %s --check-prefix=GLOB-AS

		@@ -1,4 +1,4 @@
		// RUN: %clang_cc1 -fno-sycl-force-inline-kernel-lambda -fsycl-is-device -internal-isystem %S/Inputs -triple spir64-unknown-unknown -disable-llvm-passes -emit-llvm %s -o - \| FileCheck %s
		// RUN: %clang_cc1 -fno-sycl-force-inline-kernel-lambda -fsycl-is-device -internal-isystem %S/Inputs -triple spir64-unknown-unknown -disable-llvm-passes -emit-llvm -fsycl-force-glob-as-in-kernel-args %s -o - \| FileCheck %s

Conversation

Fznamznon commented Apr 15, 2026

Uh oh!

bader left a comment

Choose a reason for hiding this comment

Uh oh!

elizabethandrews left a comment

Choose a reason for hiding this comment

Uh oh!

tahonermann left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Fznamznon commented Apr 22, 2026

Uh oh!

tahonermann left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Fznamznon commented Apr 23, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants