Skip to content

[BACKEND] Fix CANN 8.5.1 bishengir compatibility - #967

Open
Joiin0392 wants to merge 1 commit into
flagos-ai:triton_v3.5.xfrom
Joiin0392:cann851-compat
Open

[BACKEND] Fix CANN 8.5.1 bishengir compatibility#967
Joiin0392 wants to merge 1 commit into
flagos-ai:triton_v3.5.xfrom
Joiin0392:cann851-compat

Conversation

@Joiin0392

Copy link
Copy Markdown

Description

FlagTree triton_v3.5.x targets LLVM 22 era MLIR syntax, but CANN 8.5.1's bishengir toolchain (2026-02, commit e4e2ba9841d1) is older and cannot parse three MLIR constructs emitted by FlagTree's compiler. This causes all Triton kernel compilations on Ascend to fail, making FlagGems kernels non-functional on CANN 8.5.1.

Root Cause

Three incompatibilities between FlagTree MLIR emission and CANN 8.5.1 bishengir:

  1. bufferization.to_tensor result type clause — FlagTree's triton-opt emits bufferization.to_tensor ... to tensor<...> with a result-type clause that bishengir cannot parse.

  2. .mlirbc bytecode — FlagTree emits MLIR bytecode (.mlirbc) for inter-tool communication, but bishengir-opt cannot read the newer bytecode version.

  3. --link-aicore-bitcode flag — FlagTree passes --link-aicore-bitcode=<path> to bishengir-compile, but CANN 8.5.1's bishengir-compile does not recognize this parameter.

  4. Integer pow() dtypelibdevice.pow() passes integer arguments directly to the SIMT path, but bishengir does not support integer pow.

Changes

compiler.py (3 fixes):

  1. Add _normalize_mlir_text_for_bishengir(): strips to tensor<...> result-type clause from bufferization.to_tensor lines while keeping restrict writable (required by One-Shot Analysis).

  2. Set NPUOptions.use_bytecode = False: use text MLIR instead of bytecode for inter-tool transfer.

  3. Remove --link-aicore-bitcode from compile option list (replace with pass).

libdevice.py (1 fix):

Cast integer arguments to fp32 before calling the libdevice SIMT path in pow().

Testing

Environment: Ascend 910B2C x86_64 / CANN 8.5.1 (bishengir 2026-02)

# Before fix: all Triton kernel compilations fail
# After fix: FlagGems kernels compile and execute

python3 -c "
import torch
import flag_gems
flag_gems.enable()
x = torch.randn(1024, device='npu')
y = torch.relu(x)
print('FlagGems kernel OK:', y.shape)
"

Tested end-to-end with vllm-plugin-FL + FlagCX + FlagGems on Qwen3.6-35B-A3B (4-card TP=4):

  • FlagGems Triton kernels compile via bishengir ✅
  • Inference produces correct output ✅

compiler.py (3 fixes):
- Add _normalize_mlir_text_for_bishengir(): strip ' to tensor<...>'
  result-type clause from bufferization.to_tensor output, since CANN 8.5.1
  bishengir cannot parse the newer MLIR syntax emitted by triton-opt
  (keep 'restrict writable' for One-Shot Analysis)
- Disable bytecode round-trip (use_bytecode=False): CANN 8.5.1
  bishengir-opt cannot read newer .mlirbc bytecode versions
- Remove --link-aicore-bitcode flag: CANN 8.5.1 bishengir-compile
  does not recognize this parameter

libdevice.py:
- Fix pow() for integer dtypes: cast int args to fp32 before calling
  libdevice simt path, since bishengir does not support integer pow

Tested on Ascend 910B2C / CANN 8.5.1 (bishengir 2026-02, e4e2ba9841d1).
@CLAassistant

CLAassistant commented Aug 12, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants