This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Add verify method to adaptor
ClosedPublic

Authored by jpienaar on May 29 2020, 2:48 PM.

Details

Summary

This allows verifying op-indepent attributes (e.g., attributes that do not require the op to have been created) before constructing an operation. These include checking whether required attributes are defined or constraints on attributes (such as I32 attribute). This is not perfect (e.g., if one had a disjunctive constraint where one part relied on the op and the other doesn't, then this would not try and extract the op independent from the op dependent).

The next step is to move these out to a trait that could be verified earlier than in the generated method. The first use case is for inferring the return type while constructing the op. At that point you don't have an Operation yet and that ends up in one having to duplicate the same checks, e.g., verify that attribute A is defined before querying A in shape function which requires that duplication. Instead this allows one to invoke a method to verify all the traits and, if this is checked first during verification, then all other traits could use attributes knowing they have been verified.

It is a little bit funny to have these on the adaptor, but I see the adaptor as a place to collect information about the op before the op is constructed (e.g., avoiding stringly typed accessors, verifying what is possible to verify before the op is constructed) while being cheap to use even with constructed op (so layer of indirection between the op constructed/being constructed). And from that point of view it made sense to me.

Diff Detail

Event Timeline

jpienaar created this revision.May 29 2020, 2:48 PM
aartbik added inline comments.May 29 2020, 6:31 PM
mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
324

.. format context 'ctx' for
(since this is an output var, good to document)

333

nit: here and below, "unsigned int" seems slightly more idiomatic

1920

This is very minimum documentation for such an important new method....

ftynse requested changes to this revision.Jun 3 2020, 2:07 AM

Thanks! I think this is useful, and may also be helpful for some parsers that rely on specific attributes being present to interpret the syntax.

I would consider renaming OperandAdaptor to just OpAdaptor because it becomes concerned with more than operands.

mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
324

In general, a little description of what is expected in attrGet/OperandGet/resultGet would be helpful here. I see from the code that they are used as function-like objects that are called with an integer literal and should return something (presumably a range) that I don't fully grasp.

361

Same as above, could you please add a doc on what is the expected format of emitErrorPrefix (I suppose it should be a quoted string literal with a trailing space)

377

Wouldn't attrPred.getCondition() 5 lines above fail if attrPred.isNull() ?

394

This looks like we don't allow optional/default-valued attributes with conditions that require the op to be constructed. I'm not sure that's right.

405

Could you put this condition above the previous one? They are mutually exclusive and it will make it easier to match generated braces. It will also let you drop the && hasConditionToEmit from that condition, which is currently asymmetrical and confusing.

406

Nit: I belive the codestyle says to remove trailing whitespace so we shouldn't have whitespace-only lines

1637

We should document somewhere that one cannot assume anything about the order in which auto-generated attribute verifier get applied

2006

Nit: elide trivial braces

This revision now requires changes to proceed.Jun 3 2020, 2:07 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 3 2020, 2:07 AM
jpienaar updated this revision to Diff 268665.Jun 4 2020, 9:58 PM
jpienaar marked 12 inline comments as done.

Addressed review comments and changed error message so that it is the same via adaptor or via op.

jpienaar marked an inline comment as done.Jun 4 2020, 10:03 PM

I would consider renaming OperandAdaptor to just OpAdaptor because it becomes concerned with more than operands.

Agreed, but will do as purely mechanical change.

mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp
333

getNumOperands is a signed int type, I prefer not to mix signed/unsigned computations.

(Disclaimer: I also support http://lists.llvm.org/pipermail/llvm-dev/2019-June/132890.html and would prefer we consistently used ints outside bitmasks, but thats a different discussion).

394

We do allow, we just don't verify it in the adaptor as there is nothing we can verify (op may not exist yet and attribute need not be defined), it would/should be verified in the op's verify method.

1637

This is true today yes (although it is in order at present, that is an implementation detail rather than contract). We do actually want to enable an order but that is a different discussion.

[added to md doc]

ftynse accepted this revision.Jun 5 2020, 1:18 AM

Agreed, but will do as purely mechanical change.

Sure, I did not expect it to happen in this commit, just mentioning that it makes sense in the longer run.

This revision is now accepted and ready to land.Jun 5 2020, 1:18 AM
This revision was automatically updated to reflect the committed changes.