[Mlir-commits] [mlir] [mlir] Make symbol-user type verification proportional to participating IR (PR #212354)

[Will Dietz]

dtzSiFive wrote:

Some high-level thoughts:

**First:**
The general philosophy for verifiers is they're on the simple side.  I don't know that we've crossed that boundary but something to keep in mind.  We don't want a who-verifies-the-verifiers situation.

**Second**:
There's a lot of walking done here that at compile-time we (could) know is unnecessary, and it's by leveraging this I'm hoping we can arrive at an answer that dramatically reduces the additional cost of this verification.
Basic idea is store immutable bits per type/attribute/op kind.

I'm prototyping this presently.  This appears to be entirely orthogonal to our optimizations above/so far; it's a different sort of intrusive however as it still needs to store the knowledge somewhere[1].  While verification is the primary motivating user here, I think it could be leveraged elsewhere to some benefit as well beyond verification, such as walks looking for symbol users.

* All attributes and types : we can determine in ODS whether an attribute/type is known to necessarily be "symbol ref free".  We can compute this as a simple fold over their structure at generation time.  The answer would tentatively end up set in `AbstractType`/`AbstractAttribute`, as an immutable bit set at registration.
* All operations: for all inherent attributes and for all operand and result types, are they "symbol ref free"?  If so, only look to their discardable attributes.  This would tentatively live in OperationName.

How do we feel about this sort of direction?

[1] Ideas welcome for ways to capture this static information for our use that are less intrusive and ideally extensible for other use cases!

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