This is an archive of the discontinued LLVM Phabricator instance.

[mlir][DeclarativeParser] Add basic support for optional groups in the assembly format.
ClosedPublic

Authored by rriddle on Feb 15 2020, 11:19 PM.

Details

Summary

When operations have optional attributes, or optional operands(i.e. empty variadic operands), the assembly format often has an optional section to represent these arguments. This revision adds basic support for defining an "optional group" in the assembly format to support this. An optional group is defined by wrapping a set of elements in () followed by a ? and requires the following:

  • The first element of the group must be either a literal or an operand argument.
    • This is because the first element was be optionally parsable.
  • There must be exactly one argument variable within the group that is marked as the anchor of the group. The anchor is the element whose presence controls whether the group should be printed/parsed. An element is marked as the anchor by adding a trailing ^.
  • The group must only contain literals, variables, and type directives.
    • Any attribute variables may be used, but only optional attributes can be marked as the anchor.
    • Only variadic, i.e. optional, operand arguments can be used.
    • The elements of the type directive must be defined within the same optional group.

An example of this can be seen with the assembly format for ReturnOp, which has a variadic number of operands.

def ReturnOp : ... {
  let arguments = (ins Variadic<AnyType>:$operands);

  // We only print the operands+types if there are a non-zero number
  // of operands.
  let assemblyFormat = "attr-dict ($operands^ `:` type($operands))?";
}

Depends On D74648

Diff Detail

Event Timeline

rriddle created this revision.Feb 15 2020, 11:19 PM
antiagainst added inline comments.Feb 21 2020, 12:07 PM
mlir/docs/OpDefinitions.md
655

It's sort of counter intuitive for me to see this. I'd assume something like ($operands : type($operands))? would be more natural. But maybe that's drawing too much from regex background. What about something like ($operands^ : type($operands))? so one uses ^ to mean anchor and still retain overall similarity with regex?

655

Reformat:

It's sort of counter intuitive for me to see this. I'd assume something like ($operands : type($operands))? would be more natural. But maybe that's drawing too much from regex background. What about something like ($operands^ : type($operands))? so one uses ^ to mean anchor and still retain overall similarity with regex?

Implementation looks good to me.

rriddle updated this revision to Diff 245971.Feb 21 2020, 1:10 PM
rriddle marked 3 inline comments as done.

Resolve comments

rriddle added inline comments.Feb 21 2020, 1:13 PM
mlir/docs/OpDefinitions.md
655

I was reaching for something like this but glossed over using ^. Looks much better now, thanks Lei!

antiagainst accepted this revision.Feb 21 2020, 1:44 PM

Nice! Thanks!

This revision is now accepted and ready to land.Feb 21 2020, 1:44 PM

Don't forget to update the CL message too.

rriddle edited the summary of this revision. (Show Details)Feb 21 2020, 1:54 PM
This revision was automatically updated to reflect the committed changes.