[Mlir-commits] [mlir] [mlir][affine] Allow `memref.cast` in `isDimOpValidSymbol` (PR #74401)
Matthias Springer
llvmlistbot at llvm.org
Wed Dec 13 15:54:02 PST 2023
matthias-springer wrote:
> (1) verifiers can look at ancestor operations (otherwise, we cannot verify, e.g., that a terminator is nested in a specific operation)
Things like these can often be verified by traits (e.g., `ParentOneOf`), so you could argue that this is not a violation of any rules/best practices of a hand-written verifier.
> Not sure if they can get into a catastrophic case where the verifier assumes that another operation was verified, e.g. to APIs of this operation, but the operation is in fact invalid and hasn't been verified.
I haven't seen any such cases. I see this mostly as a composability issue. `affine.for` verifies that its operands are defined by a hard-coded list of ops from __another__ dialect (memref dialect). There could be a canonicalization pattern in the memref dialect that replaces a memref op with another one that is not in the hard-coded list (e.g., because we forgot to add it, as shown in this example. or because its a newly added op). now the canonicalization pattern produces invalid IR because of some complex verification in another dialect.
https://github.com/llvm/llvm-project/pull/74401
More information about the Mlir-commits
mailing list