[Mlir-commits] [mlir] [mlir][vector] Clarify the semantics of BroadcastOp (PR #101928)
Andrzej Warzyński
llvmlistbot at llvm.org
Tue Aug 6 02:39:03 PDT 2024
================
@@ -367,6 +367,8 @@ def Vector_BroadcastOp :
s_1 x .. x s_j x .. x s_k
<duplication> <potential stretch>
```
+ * a scalable unit dimension, `[1]`, must match exactly.
----------------
banach-space wrote:
It always takes me a while to parse the previous two conditions. And this one is meant to be read together 😅 It feels that we should be able to phrase this better, but I'm failing to find a better description.
Here are some examples:
**Example 1**
The following makes sense for fixed-width `1`, because there would be exactly 1 element to broadcast. Always. However, with scalable vectors (and scalable one `[1]`), there could be `1`, `2`, `4` ... elements - we won't know the actual number until run-time.
```mlir
// This is fine:
%0 = vector.broadcast %arg0 : vector<1xf32> to vector<[4]xf32>
// This ambiguous and is disabled:
%1 = vector.broadcast %arg0 : vector<[1]xf32> to vector<[4]xf32>
```
Note, that the previous condition makes an exception for "fixed width" 1:
> the sizes in the trailing dimensions n-k < i <= n with j=i+k-n match exactly as s_j = t_i or s_j = 1:
The condition that I'm adding is meant to clarify that for `[1]` there is no exception.
**Example 2**
Again, the previous condition makes an exception for "fixed width" 1 and hence the following makes sense when using `1`. Scalable one, `[1]`, requires extra restrictions:
```mlir
// The trailing dims match exactly (`1 == 1`):
%0 = vector.broadcast %arg0 : vector<1xf32> to vector<4x1xf32>
// The trailing dims match exactly (`[1] == [1]`)
%1 = vector.broadcast %arg0 : vector<[1]xf32> to vector<4x[1]xf32>
// The trailing dims do not match exactly (`1 != [1]`)
%2 = vector.broadcast %arg0 : vector<1xf32> to vector<4x[1]xf32>
```
**Tl;Dr**
If there's exactly 1 element then we can obviously broadcast that to whatever size we need. However, `[1]` doesn't not qualify as "exactly 1" :)
https://github.com/llvm/llvm-project/pull/101928
More information about the Mlir-commits
mailing list