Skip to content

[TritonIntelGPUToLLVM] Vectorize masked StoreOp when mask isn't statically uniform#7577

Draft
anmyachev wants to merge 1 commit into
mainfrom
amyachev/issue7571
Draft

[TritonIntelGPUToLLVM] Vectorize masked StoreOp when mask isn't statically uniform#7577
anmyachev wants to merge 1 commit into
mainfrom
amyachev/issue7571

Conversation

@anmyachev

Copy link
Copy Markdown
Contributor

No description provided.

…cally uniform

Signed-off-by: Anatoly Myachev <anatoly.myachev@intel.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

This PR improves TritonIntelGPUToLLVM lowering for masked triton::StoreOp when the mask is not statically uniform across the chosen vectorization width, by emitting a fast wide-store path guarded by a runtime “all-lanes-valid” predicate and falling back to exact per-element stores otherwise.

Changes:

  • Add a helper to build two-armed predicated control flow for side-effecting, result-less regions.
  • Update StoreOp lowering to keep wide vectorization even with non-uniform masks by dynamically guarding the wide store and introducing a per-element slow path fallback.
  • Update the MLIR conversion test to assert the new two-armed guarded structure and expected store widths/alignments.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
third_party/intel/lib/TritonIntelGPUToLLVM/Utility.h Adds createTwoArmedPredicatedBlock helper used to generate fast/slow guarded control flow.
third_party/intel/lib/TritonIntelGPUToLLVM/LoadStoreOpToLLVM.cpp Changes masked StoreOp lowering to prefer wide stores with a runtime group mask AND, with a scalar per-lane fallback for correctness.
test/Conversion/intel/load_store_256b_to_llvm.mlir Updates checks to validate the new guarded wide-store + scalar-fallback lowering.
Comments suppressed due to low confidence (1)

third_party/intel/lib/TritonIntelGPUToLLVM/Utility.h:108

  • Same issue as above for the slow-path callback: using std::forward here requires <utility> (not included in this header) and isn't needed for typical lambda callbacks. Calling the functor directly avoids relying on transitive includes.
  rewriter.setInsertionPointToStart(slowBlock);
  (void)std::forward<SlowFn>(slowFn)();
  cf::BranchOp::create(rewriter, loc, endBlock);

Comment on lines +102 to +104
rewriter.setInsertionPointToStart(fastBlock);
(void)std::forward<FastFn>(fastFn)();
cf::BranchOp::create(rewriter, loc, endBlock);
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.

[Pytorch] layernorm+softmax fusion from inductor has lower hardware efficiency than CUDA

2 participants