Use forward decl.

Address River's comments.

Thanks for cleaning this up!

LGTM, but ot sounds like you might want to add some more testing as well. A payload that returns an argument of the enclosing function would be enough.

Address Stephan's comments.

Fix dfki-jugr@'s comments.

Thanks! This looks great!

Remove old stray stuff and add a TOC

LGTM modulo Lei's comment.

Awesome! Thank you for pushing this herculean effort!

I think you also should do the same for

Address Stephan's comments.

Awesome!

Address River's comments.

Fix a few mentions in comments.

Did we actually get consensus around the direction here? I didn't see a clear conclusion.

One last nit.

Touch up a few more places that mention extract_element.

Partially revert https://reviews.llvm.org/D92980

You might want to link to the ProgrammersManual directly from here as well.

Remove some more stray copypasta.

Address River's comments.

In D92562#2444990, @herhut wrote:

In D92562#2443647, @silvas wrote:

Having this customizable with a callback will allow users to potentially start doing all sorts of random stuff inside. What if a user starts depending on that? For example, what if the callback references some side data structure and generates different clone/free ops depending on that, possibly in a less structured way than we would like to support upstream. That suddenly becomes much more difficult to unwind. Of course, implementing that callback is likely to be done in a downstream project, where doing something like this as a shortcut might seem more acceptable. But that shortcut then becomes a cost that the MLIR community needs to pay to unwind!

We could, for example, explicitly state that this is not allowed and that the call back should always create the same operations. Then we have a contract of what we want to support and a clear mandate to break downstream that does not follow the contract. Would that approach work for you?

I generally agree with @bondhugula on tensor.get_element being somewhat better. However, I think tensor.extract is the right thing for this patch because:

Would be nice to find a way to test this (Maybe a FileCheck test? not sure how to set that up though; don't worry if it is too much work.)

Totally agreed that MLIR is in a youthful stage. I think it is a valuable discussion to be had explicitly with the community about how we approach the tradeoffs in adopting more incremental code vs more vetted designs. Getting clarity there would greatly simplify this discussion!

Thanks. This LGTM.

In D92562#2436641, @dfki-mako wrote:

@silvas Our intention was not to "bypass anything", sorry for the confusion. As you have mentioned, the discussion went a bit "idle" and we had to more forwards to simplify the integration of the BufferDeallocation pass into other third-party sub projects. Therefore, we proposed this CL that realizes an extremely light-weight version of the Pass Interface being discussed in the forums. However, the proposed solution in the scope of this CL is meant to unblock others on the one hand and being minimally invasive on the other hand. In other words: as soon as we can come up with a better solution based on the Discourse discussion, we can easily "revert" or "update" this pass interface. Please note further that existing code will not break or require further updates after merging this CL.

The spec link doesn't seem to support AllowNumeric. Why do we have that feature?

In D92562#2435368, @tpopp wrote:

As a general matter of policy in LLVM, we do not bypass ongoing design discussions to unblock downstream users.

Just a note. It's fair to say that they should have pinged the thread one more time, but that thread had a discussion, where dfki and herhut responded to the debate and then received no response for 17 days. That's not really an ongoing discussion at that point.

In D92562#2433473, @herhut wrote:

I disagree with @silvas on this. This particular change does not take any opinion on the discussion you reference. It merely makes the hard-wired current behavior configurable by choosing different ops. It does not mandate how the decision which free operation to use is done.

Abandoned in favor of https://reviews.llvm.org/D92522

Wow, awesome work!

Replace constexpr function with old-school class with static members.

Can we please finish the discussion in https://llvm.discourse.group/t/remove-tight-coupling-of-the-bufferdeallocation-pass-to-std-and-linalg-operations/2162/12 before moving forward with this? It's not clear to me that we all agreed that this was the right direction.

Address Chris's comments about the docs.

In D92522#2429795, @dblaikie wrote:

I'm generally good with this in terms of incremental forward progress. Still don't feel super great about the "at least 1" thing and the disparate storage limits (preferred size versus break-because-too-big size), but given the varied opinions, seems like the incremental progress is probably the best path forward for now. (perfect being the enemy of good and all that)

Use SmallVector<T, 0> as the header size.

Created mistakenly (bad script). Abandoning.