Skip to content

Conversation

@premanandrao
Copy link
Contributor

This removes the following attributes:

[[intel::max_work_group_size]]
[[intel::max_global_work_dim]]
[[intel::no_global_work_offset]]
[[intel::num_simd_work_items]]
[[intel::doublepump]]
[[intel::singlepump]]
[[intel::fpga_memory]]
[[intel::fpga_register]]
[[intel::bankwidth]]
[[intel::numbanks]]
[[intel::private_copies]]
[[intel::merge]]
[[intel::max_replicates]]
[[intel::simple_dual_port]]
[[intel::bank_bits]]
[[intel::force_pow2_depth]]
[[intel::use_stall_enable_clusters]]
[[intel::scheduler_target_fmax_mhz]]
[[intel::initiation_interval]]
[[intel::max_concurrency]]
[[intel::loop_coalesce]]
[[intel::disable_loop_pipelining]]
[[intel::loop_count[_min|_max_avg]]]
[[intel::max_interleaving]]
[[intel::speculated_iterations]]
[[intel::max_reinvocation_delay]]
[[intel::enable_loop_pipelining]]
[[intel::loop_fuse]]
[[intel::loop_fuse_independent]]
attribute((register_num(n)))
attribute((pipe(mode)))
attribute((io_pipe_id)))

This removes the following attributes:

[[intel::max_work_group_size]]
[[intel::max_global_work_dim]]
[[intel::no_global_work_offset]]
[[intel::num_simd_work_items]]
[[intel::doublepump]]
[[intel::singlepump]]
[[intel::fpga_memory]]
[[intel::fpga_register]]
[[intel::bankwidth]]
[[intel::numbanks]]
[[intel::private_copies]]
[[intel::merge]]
[[intel::max_replicates]]
[[intel::simple_dual_port]]
[[intel::bank_bits]]
[[intel::force_pow2_depth]]
[[intel::use_stall_enable_clusters]]
[[intel::scheduler_target_fmax_mhz]]
[[intel::initiation_interval]]
[[intel::max_concurrency]]
[[intel::loop_coalesce]]
[[intel::disable_loop_pipelining]]
[[intel::loop_count[_min|_max_avg]]]
[[intel::max_interleaving]]
[[intel::speculated_iterations]]
[[intel::max_reinvocation_delay]]
[[intel::enable_loop_pipelining]]
[[intel::loop_fuse]]
[[intel::loop_fuse_independent]]
__attribute__((register_num(n)))
__attribute__((pipe(mode)))
__attribute__((io_pipe_id)))
Copy link
Contributor

@Fznamznon Fznamznon left a comment

Choose a reason for hiding this comment

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

I don't think ESIMD attributes should be affected by this patch.

let SimpleHandler = 1;
}

// Available in SYCL explicit SIMD extension. Binds a file scope private
Copy link
Contributor

Choose a reason for hiding this comment

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

That seems to be ESIMD attribute, i.e. specific for GPUs. Why are we removing this?

let SupportsNonconformingLambdaSyntax = 1;
}

def SYCLIntelNumSimdWorkItems : InheritableAttr {
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here, num_simd_work_items doesn't seem FPGA specific

let SupportsNonconformingLambdaSyntax = 1;
}

def SYCLIntelMaxWorkGroupSize : InheritableAttr {
Copy link
Contributor

Choose a reason for hiding this comment

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

max_work_group_size doesn't seem specific for FPGA.

Copy link
Contributor

Choose a reason for hiding this comment

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

This attribute was added in #883, where it is documented as FPGA-related. The only documentation I can find for this attribute is also FPGA-specific:

When a kernel is decorated with this C++ attribute, the compiler adds the MaxWorkgroupSizeINTEL execution mode to the kernel's SPIR-V. @vmustya and @bashbaug, does IGC do anything useful when this execution mode is present on a kernel which runs on GPU?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not too familiar with the scalar IGC. @PawelJurek, could you please comment?

Copy link
Contributor

Choose a reason for hiding this comment

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

I did a quick test and it doesn't look like IGC is (currently) rejecting SPIR-V modules that declare use of the SPV_INTEL_kernel_attributes extension and apply the MaxWorkgroupSizeINTEL execution mode, but it doesn't look like we are doing anything with it either, and I am able to enqueue kernels with a local work size that exceeds the specified values.

I also did a quick search through the IGC repo and didn't see any place where we are checking for this execution mode, either via the symbolic name MaxWorkgroupSizeINTEL or the ID value 5893.

For completeness, our CPU device also rejects modules that declare the KernelAttributesINTEL capability:

Compilation started
Unsupported SPIR-V module
SPIRV module requires unsupported capability 5892
Compilation failed

So in summary: Although the attribute could in theory be useful to non-FPGA devices, I don't think we're doing anything with it right now.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks, @bashbaug. This confirms my belief that we added this attribute for FPGA, and I think it makes sense to remove it. I do not think we should keep it around just because it might be useful someday. We can always add it back later if we find a need. In any case, we probably wouldn't use a C++ attribute even if we did find some other use for this. We'd instead add a compile-time kernel property.

BTW, we also have a SYCL compile-time property max_work_group_size which sets the same SPIR-V execution mode. I'll file a tracker to deprecate/remove that too. (This will affect the SYCL runtime headers, not the CFE.)

@Fznamznon Fznamznon requested a review from gmlueck January 22, 2026 11:30
Copy link
Contributor

@AaronBallman AaronBallman left a comment

Choose a reason for hiding this comment

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

Is there an external list of attributes we can compare this against (like in a Jira where someone identified the attributes)? The patch summary has a list, but it's hard to know whether that list was generated from what you removed or whether you removed attributes starting from that list. (Asking because there are questions about some of the attributes being removed and whether it's appropriate.)

@gmlueck
Copy link
Contributor

gmlueck commented Jan 22, 2026

Is there an external list of attributes we can compare this against (like in a Jira where someone identified the attributes)?

I believe @premanandrao was following the list I created in the Jira CMPLRLLVM-68534. Note that I did say this when I created the list:

In addition, the following attributes seem to me like they were added for FPGA. Someone in the CFE team should decide if they exist only to support FPGA devices on SYCL. If this is their only purpose, I think they should be removed:

Copy link
Contributor

@sarnex sarnex left a comment

Choose a reason for hiding this comment

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

+1 mariya i dont think we should be removing esimd attributes

@premanandrao
Copy link
Contributor Author

Is there an external list of attributes we can compare this against (like in a Jira where someone identified the attributes)? The patch summary has a list, but it's hard to know whether that list was generated from what you removed or whether you removed attributes starting from that list. (Asking because there are questions about some of the attributes being removed and whether it's appropriate.)

The list came from @gmlueck, but I tried to lookup Jira requests pertaining to each attribute for context.
The list in the description came from the Jira that was filed by Greg.

But based on internal discussions, I will split this PR into multiple ones - one for each attribute or a small set of related attributes. That should make reviewing/reverting easier.

Thanks for all the review comments so far. I will apply some changes now, but then close the PR.

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.

7 participants