[RFC, mlir, vector] Deprecate then remove `vector.splat`

MLIR
1

Motivation

vector.splat is a subset of vector.broadcast. In other words what can be expressed with splat

%v1 = vector.splat %x : vector<2x4x3xi32>

can also be represented by broadcast

%v1 = vector.broadcast %x : f32 to vector<2x4x3xi32>

vector.splat is a special case of vector.broadcast but it is easy to recognise a vector.broadcast that is a vector.splat, so if we removed vector.splat we wouldn’t lose optimization opportunities.

Maintaining vector.splat requires work. For example in the last 2 months there are 3 commits primarily about vector.splat. So, I propose investing time now to save it in the future!

History

BroadcastOp was introduced in 2019, in this commit. SplatOp was introduced in Feb 2022 here as part of the effort to remove the std dialect. It was noted there that vector.broadcast already existed. From what I can tell the general consensus there was that vector.splat should be removed as a follow-up. One other suggestion there was that vector.splat should be kept but that vector.broadcast only accepts vector operand. So I guess there are 3 options:

Option 1

Leave vector.splat and vector.broadcast as they are.

Option 2

Remove vector.splat.

Option 3

Disallow scalar operand for vector.broadcast.

Next steps

My preference would be option 2. Steps for removal could follow those of vector.extract_element and vector.insert_element in [RFC][PSA?] Remove `vector.extractelement` and `vector.insertelement` ops in favor of `vector.extract` and `vector.insert` ops

If we reach agreement on one of the options above, I am happy to explore further and define a more detailed series of steps. Help in executing would be extremely welcome!

7 Likes
2

Option 2 makes sense to me, too.

3

+1 to option 2. Thanks a lot for proposing this! Indeed, keeping both ops around has been expensive… I think this deprecation should be easier than vector.extractelements and vector.insertelements, as vector.broadcast has been used more broadly than vector.splat and existing vector.splat canonicalizations should be a subset of vector.broadcast canonicalizations. Let’s see how it goes…

1 Like
4

+1 to Option 2

Please feel free to add a link to this RFC in MLIR TCDG - Vector Dialect: Refactoring + Re-design ideas - Google Docs (there’s a bullet point under “Candidate Ops For Removal”).

Thanks for proposing this!

5

Thanks for all the positive feedback!

I’ve made some preliminary PRs. As suggested by @dcaballe it doesn’t seem like this is going to be too much effort. PR [WIP][MLIR][Vector] Deprecate vector.splat by newling · Pull Request #147818 · llvm/llvm-project · GitHub (which is just for illustration) gets us most of the way there.

IREE folks: FWIW I intend to eventually make a similar PR in IREE where there are only a few uses of vector.splat

6

I’m done with the preparation work, and think the next step is complete removal. When should this happen? I’m not familiar with the release process, do we just let this sit in a ‘deprecated’ state for a few months/years, and then remove it? Note that we now have a notice about this here: Deprecations & Current Refactoring - MLIR

7

It is not a huge change so I’d give it O(weeks), maybe 4, and then proceeded with removal.

The next llvm release starts in January: How To Release LLVM To The Public — LLVM 22.0.0git documentation and removing a single op from one of the 45 dialects with an obvious replacement scheme doesn’t sound important enough to wait that long.

2 Likes
8

Thanks. I’ll post the removal PR in a few weeks.

9

Hi all, here is the PR that completely removes vector.splat:

I’ll land it on Friday if there aren’t any remaining concerns.

3 Likes