This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Partially revert removal of old `fold` method
ClosedPublic

Authored by zero9178 on Feb 22 2023, 2:04 PM.

Details

Summary

Mehdi noted in https://reviews.llvm.org/D144391 that given the low cost of keeping the old fold method signature working and the difficulty of writing a FoldAdaptor oneself, it'd be nice to keep the support for the sake of Ops written manually in C++.
This patch therefore partially reverts the removal of the old fold method by still allowing the old signature to be used. The active use of it is still discouraged and ODS will always generate the new method using FoldAdaptors.

I'd also like to note that the previous ought to have broken some manually defined fold methods in-tree that are defined here: https://github.com/llvm/llvm-project/blob/23bcd6b86271f1c219a69183a5d90654faca64b8/mlir/include/mlir/Dialect/Affine/IR/AffineOps.h#L245 It seems like these are not part of the regressions tests however...

(also feel free to discuss whether this should be done or not in this review, I don't mind either way)

Diff Detail

Event Timeline

zero9178 created this revision.Feb 22 2023, 2:04 PM
zero9178 requested review of this revision.Feb 22 2023, 2:04 PM
zero9178 edited the summary of this revision. (Show Details)Feb 22 2023, 2:04 PM
mehdi_amini added inline comments.Feb 22 2023, 3:32 PM
mlir/test/lib/Dialect/Test/TestDialect.h
76

Before we do that, what would it take to write a FoldAdaptor here? Maybe my concern is misplaced if this isn't a lot of boilerplate.

I'd also like to note that the previous ought to have broken some manually defined fold methods in-tree that are defined here: https://github.com/llvm/llvm-project/blob/23bcd6b86271f1c219a69183a5d90654faca64b8/mlir/include/mlir/Dialect/Affine/IR/AffineOps.h#L245 It seems like these are not part of the regressions tests however...

Oh so we don't even have a build failure right now... ouch!

zero9178 added inline comments.Feb 22 2023, 3:45 PM
mlir/test/lib/Dialect/Test/TestDialect.h
76

The minimal hacky useable version would be

cpp
struct FoldAdaptorHack
{
    ArrayRef<Attributes> operands;

    FoldAdaptorHack(ArrayRef<Attributes> operands,DictionaryAttr, ArrayRef<Region>) : operands(operands) {}
}

The only requirement the implementation currently enforces is that this constructor call is valid. All other methods of FoldAdaptors within fold are actually only consumed by the users implementation of fold. The con of the above approach is that it does not meet user expectations and documentation of what adaptors are and how they work. One could of course add getters, but then you'd have to write the above boilerplate for each C++ ops.

But arguably, if one writes the Op in C++ one is seemingly fine with some boilerplate.

Right now I think we should land this: the way the API break is not a build break but a subtle runtime issue (fold not being called) can be costly in terms of debugging. That adds to the discussion of how to write a FoldAdaptor and so I don't feel we need to weigh further on the adaptor itself.

mehdi_amini accepted this revision.Feb 22 2023, 3:49 PM
This revision is now accepted and ready to land.Feb 22 2023, 3:49 PM
This revision was landed with ongoing or failed builds.Feb 22 2023, 4:06 PM
This revision was automatically updated to reflect the committed changes.