This is an archive of the discontinued LLVM Phabricator instance.

[mlir][python] Provide more convenient wrappers for std.ConstantOp
ClosedPublic

Authored by ftynse on Oct 1 2021, 9:32 AM.

Details

Summary

Constructing a ConstantOp using the default-generated API is verbose and
requires to specify the constant type twice: for the result type of the
operation and for the type of the attribute. It also requires to explicitly
construct the attribute. Provide custom constructors that take the type once
and accept a raw value instead of the attribute. This requires dynamic dispatch
based on type in the constructor. Also provide the corresponding accessors to
raw values.

In addition, provide a "refinement" class ConstantIndexOp similar to what
exists in C++. Unlike other "op view" Python classes, operations cannot be
automatically downcasted to this class since it does not correspond to a
specific operation name. It only exists to simplify construction of the
operation.

Depends On D110946

Diff Detail

Event Timeline

ftynse created this revision.Oct 1 2021, 9:32 AM
ftynse requested review of this revision.Oct 1 2021, 9:32 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 1 2021, 9:32 AM
stellaraccident accepted this revision.Oct 1 2021, 10:28 AM

LGTM modulo design feedback and nits. I don't have a strong enough opinion to insist on one way or the other. Your choice.

mlir/python/mlir/dialects/std.py
10 ↗(On Diff #376555)

Not to bike-shed this, but I never completely understood why this was a separate op on the C++ side -- it acts more like a named builder.

For the Python side, could we just have something like:

class ConstantOp:
  @classmethod
  def create_index(cls, value: int, ...):
    return cls(IndexType...)
14 ↗(On Diff #376555)

I think it is fine to do this import at the top level. Just import it as private as either:

from .. import ir as _ir

or

from ..ir import IndexType as _IndexType
This revision is now accepted and ready to land.Oct 1 2021, 10:28 AM
ftynse marked 2 inline comments as done.Oct 4 2021, 2:26 AM
ftynse added inline comments.
mlir/python/mlir/dialects/std.py
10 ↗(On Diff #376555)

Sure, this was also slightly bothering me. In C++, this comes from the early vision that *Op classes are thin wrappers around Operation * with better accessors. We may create Op hierarchies similarly to what we have with ShapedType->TensorType->RankedTensorType, but we don't and the implicit assumption is one *Op class corresponds to one instance of AbstractOperation. AFAIK, ConstantOp is the only thing with such specialization.

ftynse updated this revision to Diff 376833.Oct 4 2021, 2:39 AM
ftynse marked an inline comment as done.

Address review.