This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Add a new BranchOpInterface to allow for opaquely interfacing with branching terminator operations.

Authored by rriddle on Feb 27 2020, 4:43 PM.



This interface contains the necessary components to provide the same builtin behavior that terminators have. This will be used in future revisions to remove many of the hardcoded constraints placed on successors and successor operands. The interface initially contains three methods:

// Return a set of values corresponding to the operands for successor 'index', or None if the operands do not correspond to materialized values.
Optional<OperandRange> getSuccessorOperands(unsigned index);

// Return true if this terminator can have it's successor operands erased.
bool canEraseSuccessorOperand();

// Erase the operand of a successor. This is only valid to call if 'canEraseSuccessorOperand' returns true.
void eraseSuccessorOperand(unsigned succIdx, unsigned opIdx);

Depends On D75313

Diff Detail

Event Timeline

rriddle created this revision.Feb 27 2020, 4:43 PM
mravishankar resigned from this revision.Mar 4 2020, 10:29 AM

Nice. This cleans up successor access. Thanks River!

antiagainst accepted this revision.Mar 4 2020, 2:48 PM

Cool! I just have a few nits.


Use back tick for quotes to be consistent with others?


Minor issue: I see we have a few range concepts: the whole range for all the operands and the partial range for a specific operand. We use index to mean indexing into both. What about using "offset" for the latter to differentiate?


remove "what".


Nit: can you sort traits alphabetically?


Nit: Number typically makes me think about count or something. What about Index? But I see we also have getOperandNumber(). So meh. Up to you. :)

This revision is now accepted and ready to land.Mar 4 2020, 2:48 PM
rriddle updated this revision to Diff 248532.Mar 5 2020, 10:11 AM
rriddle marked 5 inline comments as done.

Address comments

Thanks for the review Lei!

This revision was automatically updated to reflect the committed changes.

This commit introduces a circular library dependence with the dialects.
Can this be part of the Standard dialect instead, or maybe lib/IR if it is fundamental?

This commit introduces a circular library dependence with the dialects.

Yes thanks, all of the interfaces in analysis are going to be moved out of Analysis in a followup.

Can this be part of the Standard dialect instead,

It doesn't really make sense to put an interface definition inside of a specific dialect.

or maybe lib/IR if it is fundamental?

IR/ should be kept clean, otherwise it will become a dumping ground for interfaces(like it is for traits ATM unfortunately).