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

[David Greene via llvm-dev]

Adam Nemet via llvm-dev <llvm-dev at lists.llvm.org> writes:

>     I spent some time chatting with Adam about this and have a better
>     understanding of his concerns here. It seems to me that if having
>     masking intrinsics is the long-term solution we want, we should do
>     that now (for add and sub) rather than building arbitrary matrix
>     layout info into intrinsics, since a mask has all the information
>     that we actually need.
>
> I think that sounds like a reasonable compromise. We already have
> masked load/store intrinsics so adding add and sub just follows that
> precedent. If the decision is made to move masking to the core
> operations, the new intrinsics would just move as well.

How will existing passes be taught about the new intrinsics?  For
example, what would have to be done to instcombine to teach it about
these intrinsics?  Let's suppose every existing operation had an
equivalent masked intrinsic.  Would it be easier to teach all of the
passes about them or would it be easier to teach the passes about a mask
operand on the existing Instructions?  Would it be easier to teach isel
about all the intrinsics or would it be easier to teach isel about a
mask operand?

I honestly don't know the answers to these questions.  But I think they
are important to consider, especially if intrinsics are seen as a bridge
to first-class IR support for masking.

                                 -David