search for: applymask

...ve the intended purpose, it would also enlarge and complicate IR, even in code that doesn't need masks. It's a common use-case to have a single mask used by many adjacent instructions, so this would also be highly redundant. An alternative that exploits this common use-case is to add a new applymask instruction: %w = applymask <2 x f32> %v, <2 x i1> %m The semantics would be to copy %v into %w, and implicitly apply mask %m to all users (recursively) of %w, unless overridden by another applymask. For example: %p = applymask <2 x f32*> %q, <2 x i1> %m %x = load &...

...o just check whether the mask registers are the same, though you could imagine walking back through the use-def chains to do more complex analysis. Esentially, the mask operand becomes part of the expression you're trying to match. CSE definitely needs to be changed to understand masks. With applymask, things look something like this: applymask: %m1 = ... %m2 = ... %r5 = applymask %r2, %m1 %r6 = applymask %r3, %m1 %r7 = applymask %r2, %m2 %r8 = applymask %r3, %m2 %r1 = add %r5, %r6 %r4 = add %r7, %r8 This is interesting because CSE will not do the optimization since the operands of the adds ar...

On Tuesday 05 August 2008 12:39, Dan Gohman wrote: > On Tue, August 5, 2008 8:32 am, David Greene wrote: > > On Monday 04 August 2008 17:56, Dan Gohman wrote: > >> The applymask approach leverages use-def information rather than > >> what can be thought of as duplicating a subset of it, making the IR > > > > I don't understand what you mean by "duplicating" here. > > If you look just at the case where every instruction in a > giv...

On Tue, August 5, 2008 8:32 am, David Greene wrote: > On Monday 04 August 2008 17:56, Dan Gohman wrote: >> The applymask approach leverages use-def information rather than >> what can be thought of as duplicating a subset of it, making the IR > > I don't understand what you mean by "duplicating" here. If you look just at the case where every instruction in a given use-def sub-dag uses the s...

...ers are the same, > though > you could imagine walking back through the use-def chains to do more > complex analysis. Esentially, the mask operand becomes part of the > expression you're trying to match. CSE definitely needs to be > changed to understand masks. > > With applymask, things look something like this: > > applymask: > %m1 = ... > %m2 = ... > %r5 = applymask %r2, %m1 > %r6 = applymask %r3, %m1 > %r7 = applymask %r2, %m2 > %r8 = applymask %r3, %m2 > %r1 = add %r5, %r6 > %r4 = add %r7, %r8 > > This is interesting because CSE will...

...If you are using a value based CSE, you can easily CSE expressions with different masks. I'd agree with lexical expression based CSE, you can't, but that's a pretty weak form of CSE. > > Using a mask-per-operation setup, code might look like this: > >... .. > > With applymask, things look something like this: > > applymask: > %m1 = ... > %m2 = ... > %r5 = applymask %r2, %m1 > %r6 = applymask %r3, %m1 > %r7 = applymask %r2, %m2 > %r8 = applymask %r3, %m2 > %r1 = add %r5, %r6 > %r4 = add %r7, %r8 > > This is interesting because CSE will...

Dan, On Aug 2, 2008, at 2:47 PM, Dan Gohman wrote: > Masks would not themselves be maskable. That is, the result of an > applymask could not be used (even indirectly) as the second operand > of another applymask. What is the motivation behind this restriction ? - Devang

...a > single mask used by many adjacent instructions, so this would also be > highly redundant. But explicit is better than implicit in my experience. It's also the LLVM philosophy to be as explicit as possible. > An alternative that exploits this common use-case is to add a new > applymask instruction: > > %w = applymask <2 x f32> %v, <2 x i1> %m > > The semantics would be to copy %v into %w, and implicitly apply mask %m > to all users (recursively) of %w, unless overridden by another > applymask. For example: > > %p = applymask <2 x f32*&gt...

...cent instructions, so this would also be >> highly redundant. > > But explicit is better than implicit in my experience. It's also > the LLVM > philosophy to be as explicit as possible. > >> An alternative that exploits this common use-case is to add a new >> applymask instruction: >> >> %w = applymask <2 x f32> %v, <2 x i1> %m >> >> The semantics would be to copy %v into %w, and implicitly apply >> mask %m >> to all users (recursively) of %w, unless overridden by another >> applymask. For example: >>...

On Aug 3, 2008, at 3:39 AM, Duncan Sands wrote: > Hi, > >> The set of instructions requiring mask legalization would be found by >> recursively traversing the uses of all applymask instructions. > > what if the applymask is in one function, but the use of it is in > another? I think we could just disallow this. If we get to the point of wanting mask-aware library routines, it might make sense to introduce an unmask instruction, which would be a sort of inverse t...

...and store nodes that in some cases would need > to be restructured if it would cope with multiple addresses at a time. Ok. I should think that this would be feasible to do. In the worst case it's an N^2 loop looking at all pairs. And N is usually going to be small. > >> %p = applymask <2 x f32*> %q, <2 x i1> %m > >> %x = load <2 x f32*>* %p ; implicitly masked by %m > >> %y = add <2 x f32> %x, %w ; implicitly masked by %m > >> %z = mul <2 x f32> %y, %y ; implicitly mas...

Hi, > The set of instructions requiring mask legalization would be found by > recursively traversing the uses of all applymask instructions. what if the applymask is in one function, but the use of it is in another? Ciao, Duncan.

...at something in B and/or C can be run > unmasked, it could be CSE'd/LICM'd/PRE'd/etc. > If D has a PHI merging a value from B and C, it might be > nice to do a vector merge. It's interesting to look at > out how these kinds of cases work under both > mask operands and applymask. Yes. Unfortunately, I'm out of spare cycles at the moment. I was thinking about this more yesterday and came up with what I think is a useful question to ask. If LLVM had had masks way back when it started, what would it look like? I realize that there are constraints on what kind of tra...

...does all of the work on masking intrinsics get thrown away at some point? I'm reminded of this now decade-old thread on gather/scatter and masking from Don Gohman, which I also mentioned in an SVE thread earlier this year: https://lists.llvm.org/pipermail/llvm-dev/2008-August/016284.html The applymask idea got worked through a bit and IIRC at some later point someone found issues with it that need to be addressed, but it's an interesting idea to consider. I wasn't too hot on it at the time but it may be a way forward. In that thread, Tim Foley posted a summary of options for mask suppo...

Hi, I've done work on predicated SIMD representations for LLVM. If you search through the archives, you may find my "applymask" proposal, which is an attempt at representing predication in a very comprehensive way. I've since stopped pushing the proposal in part because Larrabee's changing fortunes led to a decline of interest at the time, in part because the proposal doesn't look intuitive to people who d...

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

On Mon, 30 Jul 2018 at 20:57, David A. Greene via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I'm not sure exactly how the SVE proposal would address this kind of > operation. SVE uses predication. The physical number of lanes doesn't have to change to have the same effect (alignment, tails). > I think it would be unlikely for anyone to need to change the vector >

Hello, I'm working on a compiler based on LLVM for a SIMD architecture that supports instruction predication. We would like to implement branching on this architecture using predication. As you know the LLVM-IR doesn't support instruction predication, so I'm not exactly sure on what is the best way to implement it. We came up with some ways to do it in LLVM: - Do not add any