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

David Greene via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 19 14:21:30 PST 2018

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

More information about the llvm-dev mailing list