Rewrite and document multi-buffering properly:
1. Use IndexingUtils / StaticValueUtils instead of duplicating functionality
2. Properly plumb RewriterBase through.
3. Add support
4. Better debug messages.
This revision is otherwise almost NFC, if it weren't for the extra DeallocOp
support that would previoulsy make multi-buffering fail.
Depends on: D145036
Differential Revision: https://reviews.llvm.org/D145055
Allow user to apply multi-buffering transformation for cases where proving
that there is no loop carried dependency is not trivial. In this case user needs
to ensure that the data are written and read in the same iteration otherwise the
result is incorrect.
Differential Revision: https://reviews.llvm.org/D144227
`alloc`s that have users outside of loops are guaranteed to fail in
`multibuffer`.
Instead of exposing ourselves to that failure in the transform dialect,
filter out the `alloc`s that fall in this category.
To be able to do this filtering we have to change the `multibuffer`
transform op from `TransformEachOpTrait` to a plain `TransformOp`. This is
because `TransformEachOpTrait` expects that every successful `applyToOne`
returns a non-empty result.
Couple of notes:
- I changed the assembly syntax to make sure we only get `alloc` ops as
input. (And added a test case to make sure we reject invalid inputs.)
- `multibuffer` can still fail pretty easily when you know its limitations.
See the updated `op failed to multibuffer` test case for instance.
Longer term, instead of leaking/coupling the actual implementation (in
this case the checks normally done in `memref::multiBuffer`) with the
transform dialect (the added check in `::apply`), we may want to refactor
how we structure the underlying implementation. E.g., we could imagine a
`canApply` method for all the implementations that we want to hook up in
the transform dialect.
This has some implications on how not to duplicate work between
`canApply` and the actual implementation but I thought I throw that here
to have us think about it :).
Differential Revision: https://reviews.llvm.org/D143747
Multibuffer will fail to apply on allocs that are used outside of loops.
This was properly caught in the current implementation but the way we report
it was broken.
Notes cannot be emitted on their own, they need to be attached to another
main diagnostic.
Long story short, change the severity of the report from Note to Error.
Differential Revision: https://reviews.llvm.org/D143729
Adapt the implementation of TransformEachOpTrait to the existence of
parameter values recently introduced into the transform dialect. In
particular, allow `applyToOne` hooks to return a list containing a mix
of `Operation *` that will be associated with handles and `Attribute`
that will be associated with parameter values by the trait
implementation of the transform interface's `apply` method.
Disentangle the "transposition" of the list of per-payload op partial
results to decrease its overall complexity and detemplatize the code
that doesn't really need templates. This removes the poorly documented
special handling for single-result ops with TransformEachOpTrait that
could have assigned null pointer values to handles.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D140979
std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
call sites block std::optional migration.
Now we have more convenient functions to construct silenceable errors
while emitting diagnostics, and the constructor is ambiguous as it
doesn't tell whether the logical error is silencebale or definite.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D137257
Add the plumbing necessary to call the memref dialect's multiBuffer
function. This will allow separation between choosing which buffers
to multi-buffer and the actual transform.
Alter the multibuffer function to return the newly created
allocation if multi-buffering succeeds. This is necessary to
communicate with the transform dialect hooks what allocation
multi-buffering created.
Reviewed By: ftynse, nicolasvasilache
Differential Revision: https://reviews.llvm.org/D133985
