[PATCH] D137730: [mlir][TilingInterface] Fix a crash in PartialTilingInterface for some inputs

Nicolas Vasilache via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 22 23:08:03 PST 2022


nicolasvasilache added a comment.

In D137730#3945094 <https://reviews.llvm.org/D137730#3945094>, @vmurali wrote:

> In D137730#3944846 <https://reviews.llvm.org/D137730#3944846>, @nicolasvasilache wrote:
>
>> `suppress` can only suppress silenceable failures, which can be ignored and leave the IR in a valid state.
>> Definite failures cannot be suppressed as they leave the IR in an invalid state.
>>
>> What you may want is to refactor the transform to safelyreturn a silenceable failure in your use case.
>
> I want to `suppress` a match failure (see changes in this differential).

`mlir::scf::tileReductionUsingScf` returns a failure to its caller which turns it into a definite error that you cannot recover from.
As I wrote earlier, `What you may want is to refactor the transform to safely return a silenceable failure in your use case.`.
This means making `mlir::scf::tileReductionUsingScf` return "more information" than a binary success/fail and us that in the transform op.
The part that is annoying is that the whole MLIR infra is very binary in its return results (i.e. there is no difference between a match failure and an execution failure, both are failures and there is no type guarantee that IR is in a correct state)

> The transform pipeline should technically see the match failure and fail to perform any subsequent transformations (like how a normal pass pipeline would).

There is no transform pipeline, just a list of transforms that are applied unconditionally.
This is very much unlike any "normal pass pipeline".
You may want to use `transform.alternatives` which will clone and try its branches until the first one succeeds.

> I just want it to not bail out in the very end, and instead return the state the IR was in before the pipeline was applied.
> More generally, if I have to apply different pipelines in some priority order (the first one to succeed will change the IR, and the rest of the pipelines will not be applied), how do I do that? (In my case, the second pipeline is a no-op transformation.)

`transform.alternatives` is likely what you are looking for ,then.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137730/new/

https://reviews.llvm.org/D137730



More information about the llvm-commits mailing list