[Mlir-commits] [mlir] [Mlir] decompose generic by unfolding projected permutation crash fix (PR #122449)

[Adam Siemieniuk]

================
@@ -69,3 +69,35 @@ func.func @broadcast_only(%x : tensor<2x16x32xf32>, %y:  tensor<2x32xf32>, %z :
 // CHECK: %[[X_bc:.+]] = linalg.broadcast ins(%[[Y]] : tensor<2x32xf32>) outs(%[[E0]] : tensor<2x16x32xf32>) dimensions = [1]
 // CHECK: {{.*}} = linalg.div ins(%[[X]], %[[X_bc]] : tensor<2x16x32xf32>, tensor<2x16x32xf32>) outs(%arg2 : tensor<2x16x32xf32>) -> tensor<2x16x32xf32>
 // CHECK-NOT: linalg.generic
+
+// -----
+
+// unsupported currently.
+
+func.func @no_decompose_on_scalar() -> tensor<2x2xi32> {
----------------
adam-smnk wrote:

> How do I un-see and recover from this? :)

Welcome to the club ;)

> Note, it's "Negative - scalar input", rather than "Negative scalar". Also, "Negative scalar" could be "-10" (i.e. ambiguous), where's "negative" as in "negative case" is not ambiguous.

I know, I know but I'm wired the other way around (first thought and all) and snake case is not the most expressive format in terms of punctuation.
Personally, I often used this `no_ACTION_CASE` convention as I look at test case naming w.r.t. file name and/or intendent pass i.e., action taken. Negative cases don't need emphasis in `invalid.mlir` file. That being said, `no_ACTION` ends up pretty verbose and not most readable either.

Thinking about it more... Perhaps `fail_name` could work? It's short and less ambiguous - I bet some edge cases exist here too. Maybe "fail" sounds a bit dramatic but it has some connection to success/failure convention already used for `LogicalResult`.

https://github.com/llvm/llvm-project/pull/122449