This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Allow empty lists for DenseArrayAttr.
ClosedPublic

Authored by akuegel on Jul 12 2022, 2:59 AM.

Diff Detail

Event Timeline

akuegel created this revision.Jul 12 2022, 2:59 AM
Herald added a project: Restricted Project. · View Herald Transcript
akuegel requested review of this revision.Jul 12 2022, 2:59 AM
rriddle added inline comments.Jul 12 2022, 3:18 AM
mlir/lib/IR/BuiltinAttributes.cpp
919

Why is it allocating one when it's empty? I would expect this to call Base::get with an empty ArrayRef.

akuegel added inline comments.Jul 12 2022, 3:22 AM
mlir/lib/IR/BuiltinAttributes.cpp
919

This is to avoid an assertion error in VectorType::get.
But a better fix is to not fire the assertion (if it turns out to be unnecessary).
But a similar workaround was already used in the patch where VectorType support for empty shapes was added:
https://reviews.llvm.org/D114387
(TypeCoverter.cpp)
I have already asked Nicolas whether VectorType::get can be fixed. If yes, then these two lines will not be needed.

rriddle requested changes to this revision.Jul 12 2022, 3:29 AM
rriddle added inline comments.
mlir/lib/IR/BuiltinAttributes.cpp
919

It's not really a valid workaround though, because it's not creating what the user intended (meaning any number of expected invariants are broken, e.g. most of the ElementsAttr are not going to work as expected). Given that VectorType can't support zero elements, we should switch this to use TensorType, just not support empty lists (which is kind of weird), or let VectorType have zero elements.

This revision now requires changes to proceed.Jul 12 2022, 3:29 AM
akuegel added inline comments.Jul 12 2022, 3:37 AM
mlir/lib/IR/BuiltinAttributes.cpp
919

As far as I understand Nicolas, the intent is to let VectorType have zero elements.

@nicolasvasilache did I understand that right? And if yes, would you be willing to take a look what would be needed to avoid the assert?

nicolasvasilache requested changes to this revision.Jul 12 2022, 3:39 AM
nicolasvasilache added inline comments.
mlir/lib/IR/BuiltinAttributes.cpp
919
But a similar workaround was already used in the patch where VectorType support for empty shapes was added:
https://reviews.llvm.org/D114387

You're confusing MLIR vector and LLVM vectors: MLIR vector support 0-D and should work with empty in general, as I mentioned separately they already do.
E.g. in that same PR you link we have: if (vectorType.getRank() == 0) { 0-D vectors are a thing in MLIR.

However LLVM does not know about this and we must convert to llvm.vector<1xT>since we use the same MLIR VectorType representation for MLIR and LLVM the type conversion when lowering to LLVM is vector<T> (for MLIR) -> vector<1xT> (for LLVM).

I am still unclear what problem you are hitting, can you please send a standalone .mlir to repro?

akuegel updated this revision to Diff 443908.Jul 12 2022, 3:50 AM

Fix creating of VectorType when we have 0 elements.

mlir/lib/IR/BuiltinAttributes.cpp
919

ok so from offline discussion it seems you are trying to build vector<0xT>; this is indeed illegal, you want to build vector<T> for such cases with an empty shape.

akuegel added a comment.EditedJul 12 2022, 3:52 AM

Thanks Nicolas for pointing out the real problem: we should not use VectorType::get(0, elementType) for 0-d vector. I have rewritten this part in BuiltinAttributes.cpp to already pass an ArrayRef to the getShapedType methods.

nicolasvasilache accepted this revision.Jul 12 2022, 3:53 AM

ok, works for me now, please wait for River to stamp

rriddle accepted this revision.Jul 12 2022, 1:03 PM
rriddle added inline comments.
mlir/test/IR/attribute.mlir
525

Can we drop the empty space from the syntax?

This revision is now accepted and ready to land.Jul 12 2022, 1:03 PM
akuegel updated this revision to Diff 444163.Jul 12 2022, 11:53 PM

Get rid of unnecessary space when printing an empty list with type.

akuegel marked an inline comment as done.Jul 12 2022, 11:55 PM

Thanks for the review, and for pointing out a better way than the workaround I had :)

This revision was automatically updated to reflect the committed changes.