[all-commits] [llvm/llvm-project] d814f5: [mlir][MathToXeVM] Convert fastmath math ops on si...

[Md Abdullah Shahneous Bari via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: d814f55809820baee51a23eab92c24df8f5824ce
      https://github.com/llvm/llvm-project/commit/d814f55809820baee51a23eab92c24df8f5824ce
  Author: Md Abdullah Shahneous Bari <md.abdullah.shahneous.bari at intel.com>
  Date:   2026-07-28 (Tue, 28 Jul 2026)

  Changed paths:
    M mlir/include/mlir/Conversion/Passes.td
    M mlir/lib/Conversion/MathToXeVM/CMakeLists.txt
    M mlir/lib/Conversion/MathToXeVM/MathToXeVM.cpp
    M mlir/test/Conversion/MathToXeVM/math-to-xevm.mlir

  Log Message:
  -----------
  [mlir][MathToXeVM] Convert fastmath math ops on size-1 vectors (#211921)

SPIR-V has no size-1 vector type, so `convert-math-to-xevm` previously
rejected `math.exp fastmath<fast> : vector<1xf32>` (and the other native
OCL patterns), leaving them as unconverted `math.exp`. These degenerate
size-1 vectors are the result of the XeGPU pipeline distributing and
linearizing larger vectors down to a single element per lane, so in
practice fastmath exps in e.g. flash-attention softmax were never
lowered to `__spirv_ocl_native_exp`, hurting performance.

Handle size-1 vectors by unwrapping them to the scalar element type:
`vector.extract [0]` -> scalar native intrinsic -> `vector.broadcast`
back. `vector::ExtractOp`/`BroadcastOp` are marked legal in the
conversion target so the partial conversion does not roll back, and the
pass now depends on the Vector dialect.

---------

Co-authored-by: Claude Opus 4.8 <noreply at anthropic.com>



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications