<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/71326>71326</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Possible bug in `convert-vector-to-scf`
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          srcarroll
      </td>
    </tr>
</table>

<pre>
    There appears to be a bug in the `convert-vector-to-scf` where converting certain `vector.transfer_read` ops causes an invalid `memref.load` op to be created.  Maybe the input IR that causes this is incompatible with the pass, but I think a proper error check should be done rather than let the implementation create an invalid op.

Example IR:

```
#map1 = affine_map<(d0, d1, d2, d3) -> (d0, 0, 0, d3)>
#map2 = affine_map<(d0, d1, d2, d3, d4) -> (d0, 0, 0, d3)>
func.func @main(%subview:  memref<1x1x1x?xi32, strided<[17, 17, 17, 1], offset: ?>>, %c0 : index, %c0_i32 : i32, %2: vector<1x32xi1>) -> vector<1x1x1x32xi32> {
    %3 = vector.transfer_read %subview[%c0, %c0, %c0, %c0], %c0_i32, %2 {in_bounds = [true, true, true, true], permutation_map = #map1} : memref<1x1x1x?xi32, strided<[17, 17, 17, 1], offset: ?>>, vector<1x1x1x32xi32>
    return %3 : vector<1x1x1x32xi32>
}
```

Applying `mlir-opt --convert-vector-to-scf` to this IR yields the following error
```
transfer-read.mlir:4:10: error: 'memref.load' op incorrect number of indices for load
    %3 = vector.transfer_read %subview[%c0, %c0, %c0, %c0], %c0_i32, %2 {in_bounds = [true, true, true, true], permutation_map = #map1} : memref<1x1x1x?xi32, strided<[17, 17, 17, 1], offset: ?>>, vector<1x1x1x32xi32>
         ^
transfer-read.mlir:4:10: note: see current operation: %8 = "memref.load"(%4, %0, %0) <{nontemporal = false}> : (memref<1xvector<32xi1>>, index, index) -> vector<32xi1>
```

Note that the IR gets successfully transformed with the `full-unroll` option turned on.  Applying `mlir-opt ---convert-vector-to-scf=full-unroll` yields

```
  func.func @main(%arg0: memref<1x1x1x?xi32, strided<[17, 17, 17, 1], offset: ?>>, %arg1: index, %arg2: i32, %arg3: vector<1x32xi1>) -> vector<1x1x1x32xi32> {
 %0 = vector.splat %arg2 : vector<1x1x1x32xi32>
    %1 = vector.extract %arg3[0] : vector<1x32xi1>
    %2 = vector.transfer_read %arg0[%arg1, %arg1, %arg1, %arg1], %arg2, %1 {in_bounds = [true]} : memref<1x1x1x?xi32, strided<[17, 17, 17, 1], offset: ?>>, vector<32xi32>
    %3 = vector.insert %2, %0 [0, 0, 0] : vector<32xi32> into vector<1x1x1x32xi32>
 return %3 : vector<1x1x1x32xi32>
  }
  ```
  
  This makes me believe that it should also work without the option, since in this case all the leading dims are size `1` and thus any loops that get generated would be trivial single iteration loops that would canonicalize away.  Which, as far as I can tell, would  be exactly what the unrolled version would generate.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJzsV81u4zYQfhr6MrAhkZLtHHxI4gTIoUURLNBjQEkjiw1FCiRlx336YkjZcdJkf9BuT40dUiY5_zPfUNJ7tTOIG1besHI7k2PorNt4V0vnrNazyjbHzZcOHYIcBpTOQ7BQIUioxh0oA6FDYMustmaPLsz3WAfr5sHOfd2yZQaHSDxtK7ODGl2QyhBROrwIThrfontyKBuisYOHWo4ePUgDyuylVg0R9Ng7bBfans5N2tQOZcBmAfCLPFYYlVJmGAM8PELoZDixC53yQF9T236QQVUa4aBCF0kG6T3jt1ARIZ01zyBhcHZAB-icdVB3WD-D7-yoG5LcWIPgZOjQkSADGkMS3w8aezRBBmXNpOGlOXZYsGzLsus03r1IooCHRyauLzfYMpu-6ScXvRxyYGILsm2VwadeDkzcMr5uMtK-yePI4ygYv4I5E3dw3n8d4i4Td5ec-Q9wvoWm-H7-7WjqBQ3AiqyXyjC-Zrz0Y7VXeGDiGiDFl4nb_IU-TNy_KBHF-eBUgw1pU97kK1p6M7JyS7NtW4-BeDFxT5LFHS0zXtYZ0LIyDb6cl56U4Gk5SWG85PQzJWbUQ_AXlUc2k50Xe_ShfcGjA1Y3yVAAIE4ievKjHIcLs8ubqMlZpQ8ekmlnhU-KkkBlnio7msZHWay8CW5EOvDhnBgN6PoxpSUFOFGmrGKrbXTHz4rDZ7579ZvDMDpzct_1NyjYavtxkcTxehj0kSCHkEMrN7dDgPn8U6gKNuHDwyMcFerGx0Jurdb2QGwiAnwo7xTdOUV3QbKYuC6YuM4zMiIRkjP46hLC-IogjLDIOawDmLGv0IFtKU1VjR5a6yAe_T-x_mFixT9W3n1XwIwNSLNHhHp0Dk0AagLRthTIcj3Zx99ElCdQKyZfZq_zFZBtqxtjTcB-sE7qyKGV2iMlMkFIZL2-8NLZsDMOJYPPODY9vAen8_HPy-NXGzA1R0rzh0fYYfDgx7pG79tR6yMkN1nXY_PaJdkyo935aOiKkPpw7HFUudiANQuAT2rvk-IT23ccU_19pQ0CfNJOpNtlPzPTkoj8fS-RbsffNhLpduJf6CWUPJf17gctw0nid0DkhBn5JQ98CU7W4axleUNY8J7Z2xSa-PCvYk90fgSe6KMLd338eAag6L70mH8OP-X2P8ORj734BnmV8ehCujNMVQ7Rla93oPdOfQ2wMsF-K3I_1gsBzt0Q4G_Vcpq_UIPr5TN66BEq1Ar3EwqocLrXSu0tHKx7jkVvx4QQqcqjj5WpMV3-Fd3UPYLUOh7SKBsq-0b1HqRD8OrPCBk5lbU0DYRupGv9EbSle34UvUP6NwSwhDSny3Vwaq-kJnk7jaDChMCXpOlwLY01qpaapMmDPC4Afu9U3ZG60kMrHU0PdBACak3riZQE4Yusgz7C4YSGCYmwgT06TxLT2ZOOi1mzEc2VuJIz3OTLqyueZ6LMZt0mz4t10TSNXMk2rwuRy_VVsVrJosqXMi-KmdrwjIs8z8p8XXKRLer1ai2EKKplVclltWRFhr1UeqH1vl9Yt5sp70fcrHLBlzMtK9Q-vq9xbvAAcZP6TrmduQ3RzKtx51mRaeWDf-USVNC4-c16H196pte3r7y6zUanN10Ig6c3En7P-P1OhW6sFrXtGb8nztM0H5z9A-vA-H3UxzN-H_X9KwAA__8n2jwL">