clang-format

Fix sanitizer issues

In D137600#3974885, @hctim wrote:

It looks like the update to Dialect/Linalg/hoisting.mlir breaks ASan, MSan and UBSan: https://lab.llvm.org/buildbot/#/builders/5/builds/29773

Replace the template with an existing function

Remove unnecessary empty line

In D137600#3948191, @mravishankar wrote:

I dont have further comments on this patch. This only landed on my radar cause of this statement `I'm going to push the change anyway. Best case scenario, it's something wrong with my compiler. Worst case scenario, it will leave a nice log of the error I'm seeing.`
I might have mis-judged the sentiment, but pushes that could cause failures would cause pain downstream (and would probably get reverted anyway). Apologies if I misread this.

Templatize function

Address comments (1/n)

Try dyn_cast

Thanks for the review!

Address comments

Rebase on main

In D127875#3864124, @dcaballe wrote:

I thought this was already in! What is missing here? Only some doc fixes? Do you need any help with that, @jsetoain?

Address comments

Agreed!

In D121304#3860608, @awarzynski wrote:

Hi @jsetoain , thanks very much for this patch! I know that you have no access to SVE hardware ATM, so it might be tricky for you to finish this. And we (Arm) would love to have this merged :) Shall I take over? I do have access to the required testing infra.

Btw, these tests run mostly fine for me, but lli behaves slightly differently to mlir-cpu-runner - I had to add return 0 for the tests to pass. So, why not just use mlir-cpu-runner instead? I suspect that that's something to do with SVE support?

Oops...

In D134632#3817111, @rriddle wrote:

Pass generation was updated such that this should already be exposed via AffineVectorizeOptions. See https://reviews.llvm.org/D134607 as an example for updating to enable auto generation of the create methods.

Move on to the new autogenerated pass builders

clang-format

Further, for these matters of style/taste, I think that barring a rationale (which can be consistency based like you point out) or strong opinions that one form is better, we should bias towards what is. That is how mature projects operate, ime, and the decision making process working something like this is kind what I'm looking for.

We don't have any of this written down, and maybe we should. Thus my comment about a style guide -- the traditional way to codify both specifics and rationale for such things.

Nice! 🙂

Apologies. Broken herald rule.

My apologies, I think one of my Herald rules didn't do what I expected. It should not have blocked anything.

Answer comments and rebase on main

Rebase on top of main with LLVM vector.insert/extract outside of experimental

Move test to ArmSVE-specific directory

Add missing constraints.

I believe this change addresses the issue with vectors being too long. I also changed the constraints to match those of the LLVM intrinsic.

Adding verification of vector sizes, allowing more modes of operation.

Brilliant! Thanks for heads up, Bradley!

Accept fixed-length insert/extract

Bad merge

In D125855#3521355, @ftynse wrote:

I am not very convinced by the motivation of LLVM backend selecting the appropriate instructions. On other platforms, we have repeatedly seen the selection being fragile and sensitive to factors beyond our control, so I would rather have the possibility to target these directly even if it is not being used by some compilations pipelnes.

Replace unrealized cast with index cast

Clang format

Rebase on main

Address reviewer comments

Address reviewer comments

Thanks for the review, Aart!

Address reviewer comments