-
Notifications
You must be signed in to change notification settings - Fork 49
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
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Tiotto, Ettore <[email protected]>
Signed-off-by: Tiotto, Ettore <[email protected]>
Signed-off-by: Tiotto, Ettore <[email protected]>
Signed-off-by: Tiotto, Ettore <[email protected]>
Signed-off-by: Tiotto, Ettore <[email protected]>
Signed-off-by: Tiotto, Ettore <[email protected]>
@@ -1,6 +1,5 @@ | |||
// RUN: triton-opt %s -triton-raise-block-pointer -canonicalize | FileCheck %s | |||
|
|||
// TODO: expand this example to 3D |
There was a problem hiding this comment.
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.
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. |
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? |
When
tt.load
andtt.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. variableTRITON_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.