search for: applymasks

Here are some ideas that came out of brainstorming during and after the dev meeting. Disclaimer: they're just ideas :-). * Vector Gather/Scatter One way to do gather/scatter would be to extend vector types to support pointer element types, and extend load, store, and getelementptr to operate on vectors of pointers. A typical gather sequence would then look like this: %vi = load <2 x

On Tuesday 05 August 2008 13:27, David Greene wrote: > Neither solution eliminates the need for instcombine to be careful and > consult masks from time to time. > > Perhaps I'm totally missing something. Concrete examples would be helpful. Ok, so I took my own advice and thought about CSE and instcombine a bit. I wrote the code by hand in a sort of pseudo-llvm language, so

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

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

...n we can say that instcombine's job is made easier by applymask. Instcombine primarily does very localized analysis, so it can look at something like this: %r0 = neg %r888 %r1 = neg %r999 %r2 = add %r0, %r1 and without knowing anything about r888 or r999 and whether or not there were applymasks involved in producing their value, it can safely do the transformation. A key rule in my initial email is that the operands of any operator must be under the same mask. The Verifier can enforce this constraint. One problem though is that this places an interesting burden on front-ends and vectoriz...

On Thu, Aug 7, 2008 at 3:13 PM, David Greene <dag at cray.com> wrote: > On Tuesday 05 August 2008 13:27, David Greene wrote: > >> Neither solution eliminates the need for instcombine to be careful and >> consult masks from time to time. >> >> Perhaps I'm totally missing something. Concrete examples would be helpful. > > Ok, so I took my own advice and

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

On Saturday 02 August 2008 16:47, Dan Gohman wrote: > * Vector Gather/Scatter > > One way to do gather/scatter would be to extend vector types to > support pointer element types, and extend load, store, and getelementptr > to operate on vectors of pointers. > > A typical gather sequence would then look like this: > > %vi = load <2 x i64>* %indices ;

On Aug 4, 2008, at 2:02 PM, David Greene wrote: > On Saturday 02 August 2008 16:47, Dan Gohman wrote: > >> * Vector Gather/Scatter >> This would complicate analyses that look at load and store addresses, >> but if we really want to do gather/scatter without messes, this >> might be >> an acceptable tradeoff. > > By "complicate" do you mean

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

On Monday 04 August 2008 17:56, Dan Gohman wrote: > > By "complicate" do you mean "need to look at multiple addresses from a > > single instruction?" Or is there more than that? I'm trying to > > understand > > all the implications. > > I mean just that -- we have a fair amount of code built around looking > at the addresses of load and

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.

On Thursday 07 August 2008 21:48, Dan Gohman wrote: > A key rule in my initial email is that the operands of any > operator must be under the same mask. The Verifier can enforce > this constraint. One problem though is that this places an > interesting burden on front-ends and vectorizers. I'll try to > write more about this soon.) I totally missed that restriction. I think

Simon Moll <moll at cs.uni-saarland.de> writes: >> 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

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

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