[BACKEND] Fix CANN 8.5.1 bishengir compatibility - #967
Open
Joiin0392 wants to merge 1 commit into
Open
Conversation
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).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
FlagTree
triton_v3.5.xtargets LLVM 22 era MLIR syntax, but CANN 8.5.1'sbishengirtoolchain (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:
bufferization.to_tensorresult type clause — FlagTree'striton-optemitsbufferization.to_tensor ... to tensor<...>with a result-type clause that bishengir cannot parse..mlirbcbytecode — FlagTree emits MLIR bytecode (.mlirbc) for inter-tool communication, but bishengir-opt cannot read the newer bytecode version.--link-aicore-bitcodeflag — FlagTree passes--link-aicore-bitcode=<path>tobishengir-compile, but CANN 8.5.1's bishengir-compile does not recognize this parameter.Integer
pow()dtype —libdevice.pow()passes integer arguments directly to the SIMT path, but bishengir does not support integerpow.Changes
compiler.py(3 fixes):Add
_normalize_mlir_text_for_bishengir(): stripsto tensor<...>result-type clause frombufferization.to_tensorlines while keepingrestrict writable(required by One-Shot Analysis).Set
NPUOptions.use_bytecode = False: use text MLIR instead of bytecode for inter-tool transfer.Remove
--link-aicore-bitcodefrom compile option list (replace withpass).libdevice.py(1 fix):Cast integer arguments to
fp32before calling the libdevice SIMT path inpow().Testing
Environment: Ascend 910B2C x86_64 / CANN 8.5.1 (bishengir 2026-02)
Tested end-to-end with vllm-plugin-FL + FlagCX + FlagGems on Qwen3.6-35B-A3B (4-card TP=4):