Skip to content

Handle conflicts with existing type during backward remat#9953

Merged
neildhar merged 1 commit into
triton-lang:mainfrom
neildhar:fix-conflicting-layout-remat
Apr 9, 2026
Merged

Handle conflicts with existing type during backward remat#9953
neildhar merged 1 commit into
triton-lang:mainfrom
neildhar:fix-conflicting-layout-remat

Conversation

@neildhar
Copy link
Copy Markdown
Collaborator

@neildhar neildhar commented Apr 8, 2026

When backward remat identifies an operand that is already in the desired
encoding, it skips that operand in the slice. However, we do not record
the desired layout for that value in layouts.

As a result, we cannot detect if we also encounter a conflicting
encoding for that same value. When that happens, the value is
rematerialised, resulting in an encoding mismatch with the user that
expected the original encoding.

To fix this, record the original encoding in layouts, without adding
it to the slice. This way, if a conflicting encoding is encountered, we
will just bail on backward remat.

@neildhar neildhar force-pushed the fix-conflicting-layout-remat branch from c9be3f7 to 59d8b7b Compare April 8, 2026 17:06
When backward remat identifies an operand that is already in the desired
encoding, it skips that operand in the slice. However, we do not record
the desired layout for that value in `layouts`.

As a result, we cannot detect if we also encounter a conflicting
encoding for that same value. When that happens, the value is
rematerialised, resulting in an encoding mismatch with the user that
expected the original encoding.

To fix this, record the original encoding in `layouts`, without adding
it to the slice. This way, if a conflicting encoding is encountered, we
will just bail on backward remat.
@neildhar neildhar force-pushed the fix-conflicting-layout-remat branch from 59d8b7b to 79aff04 Compare April 8, 2026 17:26
@neildhar neildhar marked this pull request as ready for review April 8, 2026 18:16
@neildhar neildhar requested a review from ptillet as a code owner April 8, 2026 18:16
@neildhar neildhar requested a review from ThomasRaoux April 8, 2026 18:52
@neildhar neildhar merged commit 52c0ce5 into triton-lang:main Apr 9, 2026
17 of 18 checks passed
@neildhar neildhar deleted the fix-conflicting-layout-remat branch April 9, 2026 16:55
plognjen pushed a commit to plognjen/triton that referenced this pull request Apr 14, 2026
…g#9953)

When backward remat identifies an operand that is already in the desired
encoding, it skips that operand in the slice. However, we do not record
the desired layout for that value in `layouts`.

As a result, we cannot detect if we also encounter a conflicting
encoding for that same value. When that happens, the value is
rematerialised, resulting in an encoding mismatch with the user that
expected the original encoding.

To fix this, record the original encoding in `layouts`, without adding
it to the slice. This way, if a conflicting encoding is encountered, we
will just bail on backward remat.
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