[Mlir-commits] [llvm] [mlir] [mlir][tensor][linalg] Move RelayoutOpInterface from linalg back to tensor (PR #127533)

Renato Golin llvmlistbot at llvm.org
Mon Feb 17 11:50:05 PST 2025


rengolin wrote:

> Thanks for your feedback. I'm trying to fix the [bazel build](https://buildkite.com/llvm-project/upstream-bazel/builds/125819). However, I cannot add `LinalgDialect` as a dependency of `TensorDialect`, because it would create a circle (`LinalgDialect` already depends on `TensorDialect`).

Side note: please do not propose radical code changes to fix the Bazel build. Bazel is in the peripheral tier in the LLVM support policy (https://llvm.org/docs/SupportPolicy.html#peripheral-tier) and as such, must not be the sole reason for reverting a patch.

> I'm not familiar with the (cmake) build, so I can't tell if the current form has downsides there as well. Like, do users of the tensor dialect now need to build all of linalg, but didn't need to before? And if it were the case, is it an issue?

This is what we are trying to fix. Up until now, the tensor dialect had a direct dependency with linalg, and the PR that you're trying to revert is a direct fix for that problem (plus the other surrounding PRs by @banach-space). I'm surprised this broke stuff for Bazel, given that it was already a harder dependency.

> > It's indeed a header file, but it's TableGen'ed, hence "build system" dependency. I suspect that's the undesired side-effect?
> 
> The undesired part is that it's only exposed in the 'top-level' dialect header `Linalg.h`. If it were exposed in a separate header (that Linalg.h is free to include), it would be much easier to handle from a bazel build perspective.

These two statements are at odds. If it's a table-gen'ed file, it's not `Linalg.h`. I imagine the Tensor side would just include the `.inc` directly?

https://github.com/llvm/llvm-project/pull/127533


More information about the Mlir-commits mailing list