[help wanted]adaptor advantage

in MLIR document, Operation Definition Specification (ODS) - MLIR

operand adaptor solves the problem of accessing operands provided as a list of Values without using “magic” constants. The operand adaptor takes a reference to an array of Value and provides methods with the same names as those in the operation class to access them. For example, for a binary arithmetic operation, it may provide .lhs() to access the first operand and .rhs() to access the second operand.

to my understanding, adaptor provides a aliasing method for accessing operands
for example, convolution takes ifm, kernel, and bias as operands,
to get the kernel operand, it should getOpOperand(1);
however, adaptor provides getKernel() for convenient usage.

but when compare the interfaces between op and opadaptor, adaptor is subset of op

i feel confused :frowning:
if it is just a subset, then what is the advantage it is and why adaptor is needed?

really appriciate that someone can help me :slight_smile:

There is missing context that is important for this: Dialect Conversion - MLIR

Adaptors are used during dialect conversion. Dialect conversion operates by maintaining a log of transformations that will be committed at the end if a successful lowering occurs. This is important because methods like the following will be implemented:

LogicalResult
  matchAndRewrite(Operation *op, ArrayRef<Value> operands,
                  ConversionPatternRewriter &rewriter) const;

Note that a “log” of transformations is kept, so if the producers of values consumed by op are replaced, you will see the old value in op->getOperands() and the new value in ArrayRef<Value> operands. The Adaptor is then used, so one can write adaptor.rhs() instead of operands[1].

1 Like

Tres has good example of what is probably the main use of them today.

The origin of adaptors was where one didn’t have an op yet but had the operands and attributes of which would be used to build the op. Having typed, named accessors even before the op was constructed avoided needing to know and hard coding constants. Some of the subset of interface parts is also just things no one has needed (e.g., it started only for operands and then attribute support was added much later) so if you run into something like that, please feel free to ask/file an issue.