[BACKEND] Fix asserts in 2d scan and add assert mode to layout tests #5075
Conversation
| overflow_check = """ | ||
| %17 = arith.extsi %arg2 : i32 to i64 | ||
| %18 = arith.extsi %arg3 : i32 to i64 | ||
| %19 = arith.addi %17, %18 : i64 | ||
| %i32.min = arith.constant -2147483648: i64 | ||
| %i32.max = arith.constant 2147483647: i64 | ||
| %20 = arith.cmpi slt, %19, %i32.max : i64 | ||
| %21 = arith.cmpi sge, %19, %i32.min : i64 | ||
| %22 = arith.andi %20, %21 : i1 | ||
| tt.assert %22, "overflow detected" : i1 | ||
| """ |
There was a problem hiding this comment.
isn't this likely to break often whenever we do small changes? Should this be a lit test instead?
There was a problem hiding this comment.
I want to check that the code produces the expected result, so I don't think a lit test helps here. Also not sure what changes you had in mind, this would only break if there are significant changes to the ir format which seems unlikely.
There was a problem hiding this comment.
if a pass slightly change the IR the value name may be different for instance? In general that's why in LIT tests we try not to hardcode value names.
I want to check that the code produces the expected result, so I don't think a lit test helps here.
ah right
Anyway not a blocker but we may have to find something better if it does break when changing unrelated part of the code
There was a problem hiding this comment.
if a pass slightly change the IR the value name may be different for instance?
We're providing the gpu ir directly here so there are no passes applied to this IR. The only way the argument names might change is if you manually edit the test itself.
There was a problem hiding this comment.
duh sorry I read too fast I though we were checking for this IR. scratch what I said
…t tests (triton-lang#5075)" This reverts commit 11d85f7.
|
A heads up that this change causes Python tests on AMD CI to go from ~3min to ~30min. (And it also failed on MI210 before landing but it was not blocking there.) I think it's likely due to that we use |
…riton-lang#5075) This is a follow up to triton-lang#5033 but for scan ops, and also improving the testing as it was clearly insufficient before.
This is a follow up to #5033 but for scan ops, and also improving the testing as it was clearly insufficient before.