Should linalg.indexed_generic allow for affine operations on its body?

[agostini01]

Thank you for the reply and links to the other discussion.

@nicolasvasilache

A more future-proof solution for affine to interplay more nicely with the rest of the system is proposed here: Steps towards generalizing vectorization in Affine - #9 by nicolasvasilache

Similar to the author of the post, we would like to use as much as possible of the optimization infrastructure implemented in the affine dialect.

I expect that analysis/optimizations of the affine dialect do not reason well about scf.if or std.select,cmpi (implementing affine.max,min). Is this correct?

@nicolasvasilache

increasing expressiveness to kick things down the line

That would be our use case.

It was a bit counter intuitive to have -convert-linalg-to-affine-loops failing because the body of the generic_indexed was using an affine.if op. Considering that linalg.generic_indexed ops already use affine_map<> to describe iterations/access and has an implemented lowering to affine, I was expecting it to work.

@nicolasvasilache

If you wanted to manipulate dims better then you’d probably want to lower linalg to affine.for, which is something that exists but is not actively used yet.

Uhmm… so I should not be using -convert-linalg-to-affine-loops?

@nicolasvasilache

Linalg does not want to limit itself to affine constraints and is evolving towards supporting more general iterators and data types

Yes! This makes total sense. I am not following all sparse discussions, but do you think that supporting affine.if,max,min would interact poorly with with these new (sparse) representations? Why would it be different with the suggested arith.affine_apply/min/max.

@nicolasvasilache

You could alternatively try embedding some AffineScope region […] within the linalg op.

I will investigate this solution and see if results on better optimizations down the line.

@nicolasvasilache

Orthogonally, there is also ongoing work by @gysit to create a linalg.index -like op that could help unify linalg.generic and linalg.indexed_generic.

I look forward to learn more about this work.