Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[triton-raise-block-pointer]: Introduce env. variable to ignore masked load/stores #3416

Draft
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

etiotto
Copy link
Contributor

@etiotto etiotto commented Feb 12, 2025

When tt.load and tt.store operations have a mask the compiler cannot safely "raise" them to use block pointers (block pointers load/stores are unmasked).

This PR introduces a sub option (ignore-masks) for the env. variable TRITON_INTEL_RAISE_BLOCK_POINTER. The suboption allows the compiler to rewrite masked load/stores into unmasked ones, before attempting conversion to block ptr load/stores.

@@ -1,6 +1,5 @@
// RUN: triton-opt %s -triton-raise-block-pointer -canonicalize | FileCheck %s

// TODO: expand this example to 3D
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This TODO is meaning less.

@etiotto
Copy link
Contributor Author

etiotto commented Feb 12, 2025

Note: this PR allows users to assert that the masks can be dropped (i.e. will always evaluate to true). This option is a stop-gap. I plan to work on mask analysis next.

@mfrancepillois
Copy link
Contributor

A next step in mask management could be to check whether masks ‘only’ avoid overflow (and whether they manage data flow) and to set the ‘ignore-mask’ flag if this is the case. I think the boundary control masks should be simple enough to be identified by the pass?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants