[Pytorch upstream] Wrong n_spills in combinedKernel when generate_native_code=True

[etaf]

Describe the bug

The reproducer:

nspills.py

Without generate_native_code=True:
nspills = 0
With generate_native_code=True
nspill = 2304

The nspill value is used by Inductor to determine whether two Triton kernels can be fused. Therefore, an incorrect value will negatively impact performance.

Environment details

PyTorch: pytorch/pytorch#167972 (enable generate_native_code in Inductor) or use this branch: https://github.com/pytorch/pytorch/tree/gh/etaf/173/head
Triton: release/3.6.x

GPU: PVC

[anmyachev]

It looks like in this particular case ocloc doesn't issue a warning, and we don't recompile it in large grf mode:

intel-xpu-backend-for-triton/third_party/intel/backend/compiler.py

Line 435 in 2d1ba45

if 'spilled' in output and metadata["build_flags"].find("-cl-intel-256-GRF-per-thread") == -1:

And the warnings that ocloc issues, namely the spill numbers, do not match those obtained in load_binary function.

@chengjunlu wdyt?

[chengjunlu]

It looks like in this particular case ocloc doesn't issue a warning, and we don't recompile it in large grf mode:

intel-xpu-backend-for-triton/third_party/intel/backend/compiler.py

Line 435 in 2d1ba45

if 'spilled' in output and metadata["build_flags"].find("-cl-intel-256-GRF-per-thread") == -1:
And the warnings that ocloc issues, namely the spill numbers, do not match those obtained in load_binary function.

@chengjunlu wdyt?

Yes. I think so. The output format maybe diff from version to version of ocloc. It is not defined by formal spec.
We may need to dump the information inside the zebin format directly.

@anmyachev would you like to investigate it?

[anmyachev]

We may need to dump the information inside the zebin format directly.

@anmyachev would you like to investigate it?

It looks like you've made some progress, and I've only skimmed the surface. Please continue.

[chengjunlu]

The spilling information maybe not part of the ocloc output.

We can dump the spill_size in the zebin directly as in the .ze_info section.

readelf -p ".ze_info" ./tmpsibfofaa.spv.o

String dump of section '.ze_info':
  [     0]  ---\n
            version:         '1.60'\n
            kernels:\n
              - name:            triton_\n
                  simd_size:       32\n
                  spill_size:      2304\n

Will improve the code.

[chengjunlu]

Hi @anmyachev ,

I'd like know your thinking of the way to dump the elf information since you have expereince in enabling the Triton on windows.

The possible way I have:

1. Use an third party python package like pyelftools to dump the ze binary.
2. Use a linux tools like readelf or objdump to dump the information.
3. Write an c++ utils with the #include <elf.h>.

I prefer the 1st option which is simple. But it requires the user to install extra package.

[anmyachev]

Hi @anmyachev ,

I'd like know your thinking of the way to dump the elf information since you have expereince in enabling the Triton on windows.

The possible way I have:

1. Use an third party python package like pyelftools to dump the ze binary.
2. Use a linux tools like readelf or objdump to dump the information.
3. Write an c++ utils with the #include <elf.h>.

I prefer the 1st option which is simple. But it requires the user to install extra package.

Hi @chengjunlu

I just tried pyelftools on a random bin file from Ubuntu on Windows and it seems to work. So I guess we can continue with this option.

from elftools.elf.elffile import ELFFile

with open("kernel_pvc.bin", "rb") as f:
    elf = ELFFile(f)

    sec = elf.get_section_by_name(".ze_info")
    if sec is None:
        raise RuntimeError("Section .ze_info not found")

    data = sec.data()
    text = data.decode("utf-8")
    print(text)

Output:

---
version:         '1.40'
kernels:
  - name:            kernel
    user_attributes:
      intel_reqd_sub_group_size: 32
      intel_reqd_workgroup_walk_order: [ 0, 1, 2 ]
    execution_env:
      disable_mid_thread_preemption: true
      grf_count:       128
      has_4gb_buffers: true
      has_global_atomics: true
      has_no_stateless_write: true
      simd_size:       32
      subgroup_independent_forward_progress: true
      work_group_walk_order_dimensions: [ 0, 1, 2 ]
      eu_thread_count: 8
    payload_arguments:
      - arg_type:        global_id_offset
        offset:          0
        size:            12
      - arg_type:        local_size
        offset:          12
        size:            12
      - arg_type:        arg_bypointer
        offset:          32
        size:            8
        arg_index:       0
        addrmode:        stateless
        addrspace:       global
        access_type:     readwrite
      - arg_type:        printf_buffer
        offset:          40
        size:            8
  - name:            Intel_Symbol_Table_Void_Program
    user_attributes:
      intel_reqd_sub_group_size: 16
    execution_env:
      disable_mid_thread_preemption: true
      grf_count:       128
      has_4gb_buffers: true
      has_no_stateless_write: true
      simd_size:       16
      subgroup_independent_forward_progress: true
      eu_thread_count: 8
kernels_misc_info:
  - name:            kernel
    args_info:
      - index:           0
        address_qualifier: __global
        access_qualifier: NONE
        type_name:       'char*;8'
        type_qualifiers: NONE
...

[anmyachev]

Hi @etaf, is it correct, that we need to cherry-pick 6db0083 into release branch?

[etaf]

This去feature is not targeting release 2.10，it depends on you， thanks！

…

________________________________ 发件人: Anatoly Myachev ***@***.***> 发送时间: Friday, November 28, 2025 6:17:56 PM 收件人: intel/intel-xpu-backend-for-triton ***@***.***> 抄送: Lin, Xinan ***@***.***>; Mention ***@***.***> 主题: Re: [intel/intel-xpu-backend-for-triton] [Pytorch upstream] Wrong n_spills in combinedKernel when generate_native_code=True (Issue #5544) [https://avatars.githubusercontent.com/u/45976948?s=20&v=4]anmyachev left a comment (intel/intel-xpu-backend-for-triton#5544)<#5544 (comment)> Hi @etaf<https://github.com/etaf>, is it correct, that we need to cherry-pick 6db0083<6db0083> into release branch? ― Reply to this email directly, view it on GitHub<#5544 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAR5DQ3WZMIJ3KJXNAE3IAL37AONJAVCNFSM6AAAAACNDXTTQ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKOBYG4YDGNBWGE>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[etaf]

Hi, @anmyachev sorry I'm not sure, for me it's better to add this to release branch, @riverliuintel what do you think? The static launcher feature PRs are ready（https://github.com/pytorch/pytorch/pull/168952）, but depends on this fix.