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

Mangle signed and unsigned integer types differently #1340

Merged
merged 1 commit into from
Mar 15, 2023

Conversation

peterbell10
Copy link
Contributor

This is cherry-picked from #1305

If you call a JITFunction twice in the same kernel, first with int32 then with uint32, the second call will treat the unsigned value as signed. This passes through MLIR without error because MLIR uses the same types for both, but different operation calls will be generated so you may silently get the wrong result.

This is cherry-picked from triton-lang#1305

If you call a `JITFunction` twice in the same kernel, first with
`int32` then with `uint32`, the second call will treat the unsigned
value as signed. This passes through MLIR without error because MLIR
uses the same types for both, but different operation calls will be
generated.

# Bitwise op, so expect exact equality
assert (expect[0] == to_numpy(actual[0])).all()
assert (expect[1] == to_numpy(actual[1])).all()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

On current master this fails with negative numbers in the triton ouput.

@ptillet ptillet merged commit 01b177a into triton-lang:main Mar 15, 2023
pingzhuu pushed a commit to siliconflow/triton that referenced this pull request Apr 2, 2024
…on-lang#1340)

This is cherry-picked from triton-lang#1305

If you call a `JITFunction` twice in the same kernel, first with `int32`
then with `uint32`, the second call will treat the unsigned value as
signed. This passes through MLIR without error because MLIR uses the
same types for both, but different operation calls will be generated so
you may silently get the wrong result.
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