LLVM is deprecating rollbacks from dialect conversions

[vwbaker]

This is mostly an FYI & discussion area if anyone wants to keep updating LLVM in triton, this potentially a big incoming change.

Details: https://discourse.llvm.org/t/rfc-a-new-one-shot-dialect-conversion-driver/79083

They have rolled out a flag that allows people to test this restriction before fully rolling it out: llvm/llvm-project#136490.

From briefly running the tests with this flag, I see there's quite a few failing tests at the moment including:

python/test/regression/test_cast_matmul.py
python/test/regression/test_functional_regressions.py
python/test/unit/cuda/test_tma_store_gemm.py
python/test/unit/language/test_block_pointer.py
python/test/unit/language/test_core.py
python/test/unit/language/test_core.py
python/test/unit/language/test_matmul.py
python/test/unit/language/test_pipeliner.py
python/test/unit/runtime/test_subproc.py
test/Conversion/amd/async-ops-alias-scopes.mlir
test/Conversion/amd/async_ops_to_llvm.mlir
test/Conversion/amd/buffer_load_to_local_to_llvm.mlir
test/Conversion/amd/compute-base-ptr.mlir
test/Conversion/amd/mfma-shortcut.mlir
test/Conversion/amd/tritongpu_to_llvm.mlir
test/Conversion/tritongpu_to_llvm.mlir
test/Conversion/tritongpu_to_llvm_volta.mlir

[ThomasRaoux]

Thanks for the heads up. Are you planning to work on updating this?

[vwbaker]

Not at the moment, but possibly later. I can update here if I do start working on it. It looks like AMD might be especially affected so perhaps someone from their side wants to take a look (and I know they've also been working on LLVM updates for triton).

[antiagainst]

@makslevental has a wip pull request on this: #6793

[makslevental]

yes I have 8/10 (or whatever) of the lit tests "solved" and I will squash the remainder in due course but it remains to be determined whether this is actually going to materialize into a problem (both because we don't actually do anything with the rollbacks and because it might not actually get removed).

[lezcano]

cc @Mogball who commented in the original LLVM thread

[Mogball]

I didn't follow the discussion since it was started a year ago.

I find it highly unlikely that pattern rollback will be removed. And if they do decide to do it, it will likely take at least another year, because of the upstream dialects that use it. We can honestly put it off until then.

That being said, pattern rollback is a super niche feature and I don't see any reason why we should be relying on it. I don't have much knowledge about the AMD backend, however.

Disabling it in Triton seems like the right thing anyways. It also makes compiler bugs less likely due to improper rewriter bookkeeping, which is always a constant headache.

[makslevental]

And if they do decide to do it, it will likely take at least another year, because of the upstream dialects that use it. We can honestly put it off until then.

I've been talking to Matthias about this (since the beginning of the driver rewrite). I don't think that's accurate - the upstream passes that are failing are falling for the same reason ours are (failure() even after inserting ops), they're not actually "using" the rollback (ie recovering). Those will get fixed soon. Now at the bottom of the thread TFLite shows up and complains they are actually using rollback (recovering) so they now are actually blocking removal.

[ThomasRaoux]

That being said, pattern rollback is a super niche feature and I don't see any reason why we should be relying on it

+1

Thanks @makslevental for handling this!

[Mogball]

Well TFLite was the original reason why the rollback was developed so that makes sense.