Changes needed to enable outlining by default

[newling]

Before this PR, batch matmul and convolution didn't behave as expected.

batch matmul: an error was emitted but not propagated to signal a pass failure, so the pass quietly continued

convolution: at the point of function outlining the convolution has already been decomposed into a rank-3 matmul. So it was being outlined as a matmul. Which is fine, except the generic being outlined was

 linalg.generic {indexing_maps = [#map2, #map3, #map4], 
     iterator_types = ["parallel", "parallel", "reduction"]} 
     ins(%subview_20, %subview_18 : memref<4x8xbf16, strided<[8, 1], offset: ?>, 2 : i32>, 
                                    memref<8x4xbf16, strided<[4, 1], offset: ?>, 2 : i32>) ... 

which has layouts on the memrefs. Outlining this without adjusting the types in the pass results in the error

 error: 'llvm.call' op 'generic_matmul_0_outlined' does not reference a valid LLVM function

This comes from the outlined function with signature

func.func private @generic_matmul_0_outlined(
  %arg0: memref<4x8xi8, strided<[8, 1], offset: ?>>, 
  %arg1: memref<8x8xi8, strided<[8, 1], offset: ?>>, 
  %arg2: memref<4x8xi32, strided<[8, 1]>>) 
  attributes {llvm.bareptr = true} 

trying to lower through the above function through convert-func-to-llvm results in the above error.

This PR does the following: The pass now checks if the strides on the memref are contiguous, and if they are creates a signature with memrefs without layouts. At the call site, it does a memref cast. I have confirmed that this works end-to-end for convolution (correct numerics). I guess an alternative would be just not outline in the case where the operation being outlined has operands with layouts.

[jtuyls]

In case of a non-contiguous memref, wouldn't it be better to just try continuing without outlining?

[newling]

Yes that's probably more sensible. I'll refactor to do that

[jtuyls]

LGTM