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

David Greene via llvm-dev llvm-dev at lists.llvm.org
Thu Dec 20 09:11:17 PST 2018

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 applymask was proposed to have less (redundant) predicate arguments. Unless the applymask 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

More information about the llvm-dev mailing list