This is an archive of the discontinued LLVM Phabricator instance.

[mlir][ods] Make Type- and AttrInterfaces also `Type`s and `Attr`s
ClosedPublic

Authored by zero9178 on Jul 6 2022, 8:04 AM.

Details

Summary

By making TypeInterfaces and AttrInterfaces, Types and Attrs respectively it'd then be possible to use them anywhere where a Type or Attr may go. That is within the arguments and results of an Op definition, in a RewritePattern etc.

Prior to this change users had to separately define a Type or Attr, with a predicate to check whether a type or attribute implements a given interface. Such code will be redundant now.
Removing such occurrences in upstream dialects will be part of a separate patch.

As part of implementing this patch, slight refactoring had to be done. In particular, Interfaces cppClassName field was renamed to cppInterfaceName as it "clashed" with TypeConstraints cppClassName. In particular Interfaces cppClassName expected just the class name, without any namespaces, while TypeConstraints cppClassName expected a fully qualified class name.

Diff Detail

Event Timeline

zero9178 created this revision.Jul 6 2022, 8:04 AM
Herald added a project: Restricted Project. · View Herald Transcript
zero9178 requested review of this revision.Jul 6 2022, 8:04 AM
Mogball added inline comments.Jul 6 2022, 8:45 AM
mlir/include/mlir/IR/OpBase.td
1977

Where are the values for cppNamespace and cppClassName coming from?

1988

Can you add some tblgen lit tests for these? In particular, I'm pretty sure cppNamespace will always be empty here.

Mogball requested changes to this revision.Jul 6 2022, 8:45 AM
This revision now requires changes to proceed.Jul 6 2022, 8:45 AM
zero9178 updated this revision to Diff 442609.Jul 6 2022, 9:27 AM
  • Don't use fully qualified names if cppNamespace is empty, as there exist interfaces that don't use cppNamespace, but instead are included into a namespace
  • Add test checking correctly generated constraint code.

I am not 100% sure whether the test is supposed to live in that directory, so please do tell if I should move it elsewhere.

zero9178 added inline comments.Jul 6 2022, 9:32 AM
mlir/include/mlir/IR/OpBase.td
1977

cppClassName was indeed an error of mine from back when Interface still had that field.
cppNamespace comes from Interface and may also be overwritten by the user using let statements.

The reason this works is because we inherit from Interface first. According to the TableGen language reference, classes are inherited and visited from left to right and depth first. The reason cppNamespace is correct here and also works properly even if a user only later sets cppNamespace using a let statement is that let statements are actually evaluated before any expressions of any other fields are evaluated.

See the language reference here: https://llvm.org/docs/TableGen/ProgRef.html#how-records-are-built

I added a test with both a TypeInterface and AttrInterface that set cppNamespace to show that this works.

Mogball accepted this revision.Jul 6 2022, 9:51 AM
Mogball added inline comments.
mlir/include/mlir/IR/OpBase.td
1977

even if a user only later sets cppNamespace using a let statement is that let statements are actually evaluated before any expressions of any other fields are evaluated.

Cool! I didn't know this is how it actually worked and kept it in my brain as a "TableGen black box full of magic"

mlir/test/mlir-tblgen/interfaces-as-constraints.td
11–13

nit

This revision is now accepted and ready to land.Jul 6 2022, 9:51 AM
Mogball added inline comments.Jul 6 2022, 9:55 AM
mlir/include/mlir/IR/OpBase.td
1975

You can drop the !if(!empty since prepending :: in front of class names with no namespace is what is done elsewhere.

zero9178 added inline comments.Jul 6 2022, 10:00 AM
mlir/include/mlir/IR/OpBase.td
1975

I wasn't too sure about this since there do exist interfaces in upstream that do not make use cppNamespace, but instead just include the header in a namespace of their choice. For those, using ::GlobaName would actually produce broken code. See eg: https://github.com/llvm/llvm-project/blob/f1182bd6d538847acac58316e794f5b60bc3c89a/mlir/include/mlir/Dialect/Tosa/IR/TosaOps.h#L32

If doing that instead of using cppNamespace should be discouraged/unsupported (which I am personally for) I'd very happily change it your suggestion however.

jpienaar accepted this revision.Jul 6 2022, 10:02 AM

SGTM, Attr & Type are constraints effectively and here we have interface behaving as constraint

rriddle added inline comments.Jul 6 2022, 10:21 AM
mlir/lib/Tools/PDLL/Parser/Parser.cpp
921–922

This doesn't look right, why is this creating OpConstraintDecl for all of them?

Mogball added inline comments.Jul 6 2022, 10:23 AM
mlir/include/mlir/IR/OpBase.td
1975

Sigh. Guess this is inconsistent as well.

mlir/lib/Tools/PDLL/Parser/Parser.cpp
921–922

This is only iterating over OpInterface now.

zero9178 added inline comments.Jul 6 2022, 10:24 AM
mlir/lib/Tools/PDLL/Parser/Parser.cpp
921–922

I changed the loop to only handle OpInterfaces hence it only creating OpConstraintDecl should be correct the way I read the code. TypeInterfaces and AttrInterfacess are handled via the loops above since they are now subclasses of Type and Attr.

I know very little about PDLL however, so do tell whether them not being specially handled as interfaces has any negative consequences.

rriddle added inline comments.Jul 6 2022, 10:26 AM
mlir/lib/Tools/PDLL/Parser/Parser.cpp
921–922

This will require adding a check for DeclareInterfaceMethods to the other loops now I think, we don't want to bring any of those in here.

zero9178 updated this revision to Diff 442631.Jul 6 2022, 10:33 AM

Address review comments: Make sure to also skip DeclareInterfaceMethods subclasses for Types and Attrs.