This is an archive of the discontinued LLVM Phabricator instance.

[mlir][IR] RankedShapedType::getNumElements supports non-static shapes
AbandonedPublic

Authored by springerm on Apr 17 2023, 10:51 PM.

Details

Summary

Return kDynamic in case of non-static shapes. This addresses a comment in D148453.

Depends On: D148453

Diff Detail

Event Timeline

springerm created this revision.Apr 17 2023, 10:51 PM
Herald added a project: Restricted Project. · View Herald Transcript
springerm requested review of this revision.Apr 17 2023, 10:51 PM

Why is this a better API than the assertion?

Why is this a better API than the assertion?

It seems more consistent with the other methods, e.g. getDimSize(dim) doesn't assert that the dim size is known. Also a RankedShapedType without static shape is still a valid RankedShapeType, so it seems odd for this to be a pre-condition on a method (this seems somewhat similar to the motivation for changing the ShapedType methods that required the type be ranked).

On the other hand, since kDynamic is a sentinel value, it could be easy to miss that it needs to be handled. But I think that's an issue with how kDynamic is used elsewhere as well...

Why is this a better API than the assertion?

It seems more consistent with the other methods, e.g. getDimSize(dim) doesn't assert that the dim size is known.

That does not seem comparable to me: it getDimSize(dim) returns always a valid dimension, if not known it return kDynamic, which is a valid value for a "dimension".
I don't see how getNumElements() can return anything "valid" when shapes are dynamic.

Also a RankedShapedType without static shape is still a valid RankedShapeType, so it seems odd for this to be a pre-condition on a method

I don't understand the connection you're making here?
There are many objects with methods you cannot call because of preconditions, even if the object is valid. Here a valid RankedShapeType object does not necessarily have a statically computable "number of elements".

Why is this a better API than the assertion?

It seems more consistent with the other methods, e.g. getDimSize(dim) doesn't assert that the dim size is known.

That does not seem comparable to me: it getDimSize(dim) returns always a valid dimension, if not known it return kDynamic, which is a valid value for a "dimension".
I don't see how getNumElements() can return anything "valid" when shapes are dynamic.

The interpretation would be that kDynamic is a valid value for a "shape element count" (maybe this isn't useful though, and actually I would've preferred returning something like std::optional<int64_t> instead, I just suggested kDynamic initially since it seemed like there was precedent).

Also a RankedShapedType without static shape is still a valid RankedShapeType, so it seems odd for this to be a pre-condition on a method

I don't understand the connection you're making here?
There are many objects with methods you cannot call because of preconditions, even if the object is valid.

Fair, though to make the API harder to misuse I think it'd be desirable to remove the precondition if we can find a sensible behaviour (i.e. somehow indicate that there's no statically known element count, rather than just having undefined behaviour)

Anyways I'm not convinced this should be changed either, just thought it was worth considering :)

springerm abandoned this revision.Apr 18 2023, 11:54 PM