Bump llvm

[arun-thmn]

Fix after this bump:

• Tune related code got removed as we use upstream MLIR code
• Syntax update to ConstantFloatOp and arith::ConstantIntOp creation
• ArrayRef is deprecated, so update with equivalent syntax
• linalg::vectorizer w.r.t PR:#144158
• linalg::pack w.r.t PR:#146139

[arun-thmn]

Hey @adam-smnk,
Needed your help/guidance in this LLVM bump PR. There is an update to the upstream linalg::vectorizer. Both the earlier vectorization pass and #1060 linalg-vectorizer affected.

[arun-thmn]

@adam-smnk Now, the upstream vectorized pass returns values instead of replacing [https://github.com/llvm/llvm-project/pull/144158]. So, the replacing of linalop has to be done in our passes. So, kind of fixed the problem.

Presently, trying to sort an issue with packs.

[arun-thmn]

@adam-smnk After bump LLVM, the pack is not working for few tests. One example is:

tpp-mlir/test/Passes/pack-unpack-propagation.mlir

Line 273 in 4a95804

// CHECK: %[[PACK3:.+]] = linalg.pack %[[ARG2]] outer_dims_perm = [0, 3, 1, 2] inner_dims_pos = [3] inner_tiles = [32] into %[[BUFF3]] : tensor<1x56x56x64xf32> -> tensor<1x2x56x56x32xf32>

The pack works bump IR is:
%4 = tensor.empty() : tensor<1x2x56x56x32xf32>
%pack_2 = linalg.pack %arg2 outer_dims_perm = [0, 3, 1, 2] inner_dims_pos = [3] inner_tiles = [32] into %4 : tensor<1x56x56x64xf32> -> tensor<1x2x56x56x32xf32>
%5 = tensor.empty() : tensor<2x32xf32>
%pack_3 = linalg.pack %arg3 outer_dims_perm = [0] inner_dims_pos = [0] inner_tiles = [32] into %5 : tensor<64xf32> -> tensor<2x32xf32>
%6 = linalg.generic {indexing_maps = [#map3, #map4, #map3], iterator_types = ["parallel", "parallel", "parallel", "parallel", "parallel"]} ins(%3, %pack_3 : tensor<1x2x56x56x32xf32>, tensor<2x32xf32>) outs(%pack_2 : tensor<1x2x56x56x32xf32>) {

After the bump IR:
%4 = tensor.empty() : tensor<1x2x56x56x32xf32>
%5 = tensor.empty() : tensor<2x32xf32>
%pack_2 = linalg.pack %arg3 outer_dims_perm = [0] inner_dims_pos = [0] inner_tiles = [32] into %5 : tensor<64xf32> -> tensor<2x32xf32>
%6 = linalg.generic {indexing_maps = [#map3, #map4, #map3], iterator_types = ["parallel", "parallel", "parallel", "parallel", "parallel"]} ins(%3, %pack_2 : tensor<1x2x56x56x32xf32>, tensor<2x32xf32>) outs(%4 : tensor<1x2x56x56x32xf32>) {

It might invest some time to fins out the root-cause. If you identify the problem handy (as you know the pass details), let me know please. Else, I will try to find it out.

[adam-smnk]

@arun-thmn That's probably due to recent changes in one of propagation/packing patterns.
I think this one llvm/llvm-project#146139. When %out is unused in generic's body, outs argument is no longer packed but a reshaped tensor.empty is applied directly (or sth like that).

It should be fine, I had a look at the changes and they seem correct. Just please double check the results are still correct in our test case - since it's not an integration test, just follow data manually.

[arun-thmn]

@arun-thmn That's probably due to recent changes in one of propagation/packing patterns. I think this one llvm/llvm-project#146139. When %out is unused in generic's body, outs argument is no longer packed but a reshaped tensor.empty is applied directly (or sth like that).

It should be fine, I had a look at the changes and they seem correct. Just please double check the results are still correct in our test case - since it's not an integration test, just follow data manually.

Thanks @adam-smnk, I will remove the pack from our unit-test case and will check the results.

[arun-thmn]

@adam-smnk double checked the results of pack unit-tests with tpp-run, they are good.

[adam-smnk]

LGTM % python/transform changes

[adam-smnk]

Could you also run benchmarks just to see if there are any failures there?

[arun-thmn]

Could you also run benchmarks just to see if there are any failures there?

Ran benchmarks-all no failures.