Add back barrier after asserts

[ThomasRaoux]

support asserts with scalar condition and only emit barrier for assert of tensors.
Thanks to @peterbell10 for the suggestion.

[peterbell10]

btw this highlights an interesting thing I noticed a while back. Sometimes we do the same computation in multiple different layouts when there are assert statements because the assertion path doesn't have a data flow path to the next layout anchor operation.

It's not really the end of the world, but an interesting quirk of the remove layout conversion code.

[ThomasRaoux]

right, yes this is definitely a limitation as we haven't tried very hard to make assert efficient.

[peterbell10]

Oh I think this should be

Suggested change

	if (isa<RankedTensorType>(condition.getType())) {
	if (isa<RankedTensorType>(op.getCondition().getType())) {

[ThomasRaoux]

Actually I realize now asserts should always take a tensor:

def TT_AssertOp : TT_Op<"assert", [MemoryEffects<[MemWrite<GlobalMemory>]>]> {
  let summary = "Device-side assert, as in CUDA for correctness checking";
  let description = [{
    `tt.assert` takes a condition tensor and a message string.
    If the condition is false, the message is printed, and the program is aborted.
  }];
  let arguments = (ins TT_Tensor:$condition, StrAttr:$message);
  let assemblyFormat = "$condition `,` $message attr-dict `:` type($condition)";
}

I'm now wondering how it works within a reduction region. Do we have example somewhere?

[peterbell10]

Hrm okay, an example can be the kernel in test_side_effectful_reduction. I guess we probably promote scalars to tensor in the frontend. Would it be unreasonable to add support for scalars?

[peterbell10]

I guess the region verifier isn't strong enough, but really I don't think any op that has a RankedTensor type should be allowed inside a reduction region.

[ThomasRaoux]

yeah I agree, I don't think there is any reason why the condition has to be tensor. I'll try to fix that part