This is an archive of the discontinued LLVM Phabricator instance.

[mlir] ODS: emit interface model method at the end of the header
ClosedPublic

Authored by ftynse on Oct 20 2022, 1:37 AM.

Details

Summary

Previously, ODS interface generator was placing implementations of the
interface's internal "Model" class template immediately after the class
definitions in the header. This doesn't allow this implementation, and
consequently the interface itself, to return an instance of another
interface if its class definition is emitted below. This creates
undesired ordering effects and makes it impossible for two or more
interfaces to return instances of each other. Change the interface
generator to place the implementations of these methods after all
interface classes.

Diff Detail

Event Timeline

ftynse created this revision.Oct 20 2022, 1:37 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 20 2022, 1:37 AM
ftynse requested review of this revision.Oct 20 2022, 1:37 AM
jpienaar added inline comments.
mlir/tools/mlir-tblgen/OpInterfacesGen.cpp
293

We no longer need to split post C++ version bump

Seems like a bit of an ad-hoc solution for multiple interfaces defined in the same file?

dcaballe accepted this revision.Oct 20 2022, 10:49 AM

Thanks, Alex!

This revision is now accepted and ready to land.Oct 20 2022, 10:49 AM
dcaballe requested changes to this revision.Oct 20 2022, 11:28 PM
dcaballe added inline comments.
mlir/tools/mlir-tblgen/OpInterfacesGen.cpp
459

Should we print all the fw-decls at the beginning of the file before any interface declaration so that an interface declaration can refer to another interface?

This revision now requires changes to proceed.Oct 20 2022, 11:28 PM
dcaballe added inline comments.Oct 21 2022, 3:20 PM
mlir/tools/mlir-tblgen/OpInterfacesGen.cpp
519

I've been looking at the implementation of this file to try to make it work for my use case but I get lost into the details of the autogen engine.
Assuming multiple interfaces per .td file, with this change we are still generating the following for the .h.inc file:

InterfaceA Fw-Decls
InterfaceA Decls (using InterfaceB, InterfaceB fw-decls are needed)
InterfaceA Defs (using InterfaceB, InterfaceB decls are needed)

InterfaceB Fw-Decls
InterfaceB Decls (using InterfaceA, InterfaceA fw-decls are needed)
InterfaceB Defs (using InterfaceA, InterfaceA decls are needed)

The main issue here is not the fw-decl dependency (that has an easy fix by adding the fw-decls by hand to the interface's .h file) but the decl dependency. InterfaceA needs a full declaration of InterfaceB for its definitions and vice versa. That means we would need to generate something like:

InterfaceA Fw-Decls
InterfaceB Fw-Decls

InterfaceA Decls (using InterfaceB, InterfaceB fw-decls are needed)
InterfaceB Decls (using InterfaceA, InterfaceA fw-decls are needed)

InterfaceA Defs (using InterfaceB, InterfaceB decls are needed)
InterfaceB Defs (using InterfaceA, InterfaceA decls are needed)

I don't see a simple way to generate the code in this order as it looks like each interface is processed independently? I'm missing context here but perhaps there is a way to process/register all the interfaces and only once they are all processed then generate all the code?

As a workaround I guess I can copy paste the generated code to the interface .h file and reorder it by hand. Hopefully we find a way to address this limitation.
Thanks!

This revision was not accepted when it landed; it landed in state Needs Revision.Oct 27 2022, 3:56 PM
This revision was automatically updated to reflect the committed changes.

Sorry, I accidentally committed this diff! I had it in my local branch. Should I revert it? I think it's a step in the right direction and I was able to workaround the cyclic dependency that had so this should be good enough for now if we don't want to address the more complex cases right now.