Page MenuHomePhabricator

[mlir][Vector] Thread 0-d vectors through ExtractElementOp.
ClosedPublic

Authored by nicolasvasilache on Mon, Nov 22, 12:56 PM.

Details

Summary

This revision starts making concrete use of 0-d vectors to extend the semantics of
ExtractElementOp.
In the process a new VectorOfAnyRank Tablegen OpBase.td is added to allow progressive transition to supporting 0-d vectors by gradually opting in.

Diff Detail

Event Timeline

nicolasvasilache requested review of this revision.Mon, Nov 22, 12:56 PM
Herald added a project: Restricted Project. · View Herald TranscriptMon, Nov 22, 12:56 PM

Rebase past windows build error.

dcaballe added inline comments.Tue, Nov 23, 4:15 AM
mlir/include/mlir/IR/OpBase.td
216

For how long do you think we would need this temporary definitions?

mlir/test/Conversion/VectorToLLVM/vector-to-llvm.mlir
424

I'm probably missing something obvious but why do we extract position 1 instead of 0?

Bugfixes.

mlir/include/mlir/IR/OpBase.td
216

this can go away once ops that want to use 0-d are updated and the footguns are removed.

mlir/test/Conversion/VectorToLLVM/vector-to-llvm.mlir
424

err.. because, you know .. bugs. Thanks!

gysit accepted this revision.Tue, Nov 23, 4:36 AM
gysit added a subscriber: gysit.
gysit added inline comments.
mlir/test/Conversion/VectorToLLVM/vector-to-llvm.mlir
424

I am surprised the index is not zero? From the tests above it seems like LLVM uses zero based indexing?

The example:
<result> = extractelement <4 x i32> %vec, i32 0 ; yields i32
from https://llvm.org/docs/LangRef.html#extractelement-instruction also uses index 0.

This revision is now accepted and ready to land.Tue, Nov 23, 4:36 AM
This revision was landed with ongoing or failed builds.Tue, Nov 23, 4:43 AM
This revision was automatically updated to reflect the committed changes.

@gysit @dcaballe thanks for spotting the bug, it is now fixed.

I find it quite scary that LLVM dit not complain a second about me accessing element 1 of a vector<1xf32> and produced the result I was expecting ...

gysit added a comment.Tue, Nov 23, 5:01 AM

I find it quite scary that LLVM dit not complain a second about me accessing element 1 of a vector<1xf32> and produced the result I was expecting ...

True! I assume it is lowered to n-d hardware vector and the scalar is broadcasted to all lanes?