[llvm-dev] [RFC] Matrix support (take 2)

[David Greene via llvm-dev]

Simon Moll via llvm-dev <llvm-dev at lists.llvm.org> writes:

>> True, but is there a way we could do this incrementally?  Even if we
>> start with intrinsics and then migrate to first-class support, at some
>> point passes are going to be broken with respect to masks on
>> Instructions.
>
> Here is path an idea for an incremental transition:
>
> a) Create a new, distinct type. Let's say its called the "predicated
> vector type", written "{W x double}".
>
> b) Make the predicate vector type a legal operand type for all binary
> operators and add an optional predicate parameter to them. Now, here
> is the catch: the predicate parameter is only legal if the data type
> of the operation is "predicated vector type". That is "fadd <8 x
> double>" will for ever be unpredicated. However, "fadd {8 x double}
> %a, %b" may have an optional predicate argument. Semantically, these
> two operations would be identical:
>
> fadd <8 x double>, %a, %b
>
> fadd {8 x double}, %a, %b, predicate(<8 x i1><1, 1, 1, 1, 1, 1, 1, 1>)
>
> In terms of the LLVM type hierachy, PredicatedVectorType would be
> distinct from VectorType and so no transformation can break it. While
> you are in the transition (from unpredicated to predicated IR), you
> may see codes like this:
>
> %aP = bitcast <8 x  double> %a to {8 x double}
> %bP = bitcast <8 x  double> %b to {8 x double}
> %cP = fdiv %aP, %bP, mask(11101110) ; predicated fdiv
> %c = bitcast <8 x double> %c to %cP
> %d = fadd <8 x double> %a, %c   ; no predicated fadd yet
>
> Eventually, when all optimizations/instructions/analyses have been
> migrated to run well with the new type, 1. deprecate the old vector
> type, 2. promote it to PredicatedVectorType when parsing BCand, after
> a grace period, rename {8 x double} to <8 x double>

That's an interesting idea.  It strikes me that if we went this route,
we wouldn't need intermediate intrinsics at all.  I'm trying to avoid
throw-away work, which it seems the intrinsics would be if core IR
support is the ultimate goal.

I'm not sure the renaming could ever happen.  What are the rules for
supporting older BC/textual IR files?

> The masking intrinsics are just a transitional thing. Eg, we could add
> them now and let them mature. Once the intrinsics are stable and
> proven start migrating for core IR support (eg as sketched above).

What are the tradeoffs between adding these intrinsics and adding
PredicatedVectorType from the get-go?  The latter is probably harder to
get past review, but if, say, an RFC were developed to gain consensus,
then maybe it would be easier?  I recognize that there are probably time
constraints in getting some kind of better masking support in soon and
intrinsics seems like the easiest way to do that.

> Thank for you for the pointer! Is this documented somewhere? (say in a
> wiki or some proposal doc). Otherwise, we are bound to go through
> these discussions again and again until a consensus is reached. Btw,
> different to then, we are also talking about an active vector length
> now (hence EVL).

It's not documented anywhere else AFAIK.

> AFAIU apply_mask was proposed to have less (redundant) predicate
> arguments. Unless the apply_mask breaks a chain in a matcher pattern,
> the approach should be prone to the issue of transformations breaking
> code as well.

The idea is that applymask of a single value against two different mask
values would result in two new SSA values, so existing pattern matches
would not match if the masks did not match.

> Has something like the PredicatedVectorType approach above been
> proposed before?

I believe Tim's #5 is the closest:

https://lists.llvm.org/pipermail/llvm-dev/2008-August/016371.html

I don't think it was ever fleshed out.

Perhaps we should start on an RFC to explore the design space and get
community input.  In the meantime, if we urgently need intrinsics we
should probably go ahead and start adding them.

                              -David