similar to: [LLVMdev] Ideas for representing vector gather/scatter and masks in LLVM IR

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 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

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 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 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

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

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 Aug 7, 2008, at 12:13 PM, David Greene 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

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 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 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

This thread is already churning, so I apologize if by being late to the party I have missed important information. The "apply_mask" approach is very familiar to me, in that I spent a lot of time thinking about how masking could be added pervasively to LLVM without disrupting the currently nice property that most of the standard arithmetic instructions are "overloaded" to work

Hi Renato, I fully agree with you, but indexed load and store is the next step. I'm asking to review gather and scatter code. Thanks. - Elena -----Original Message----- From: Renato Golin [mailto:renato.golin at linaro.org] Sent: Thursday, April 16, 2015 17:17 To: Demikhovsky, Elena Cc: llvmdev at cs.uiuc.edu; Chandler Carruth; James Molloy Subject: Re: [LLVMdev] Code review for gather

Hello everyone, I think I have found an gvn / alias analysis related bug, but before opening an issue on the tracker I wanted to see if I am missing something. I have the following testcase: define spir_kernel void @test(<2 x i32*> %in1, <2 x i32*> %in2, i32* %out) { > entry: > ; Just some temporary storage > %tmp.0 = alloca i32 > %tmp.1 = alloca i32 > %tmp.i =

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

this is definitely a bug in AA. 225 for (auto I = CS2.arg_begin(), E = CS2.arg_end(); I != E; ++I) { 226 const Value *Arg = *I; 227 if (!Arg->getType()->isPointerTy()) -> 228 continue; 229 unsigned CS2ArgIdx = std::distance(CS2.arg_begin(), I); 230 auto CS2ArgLoc = MemoryLocation::getForArgument(CS2, CS2ArgIdx, TLI);

Okay, so then it sounds like, for now, the right fix is to stop marking masked.gather and masked.scatter with intrarg* options. On Mon, Aug 29, 2016, 1:26 PM Philip Reames <listmail at philipreames.com> wrote: > We might have specification bug here, but we appear to implement what we > specified. argmemonly is specified as only considering pointer typed > arguments. It's

+ a few others. After following this rabbit hole a bit, there are a lot of mutually recursive calls, etc, that may or may not do the right thing with vectors of pointers. I can fix *this* particular bug with the attached patch. However, it's mostly papering over stuff. Nothing seems to know what to do with a memorylocation that is a vector of pointers. They all expect memorylocation to be a

----- Original Message ----- > From: "Daniel Berlin" <dberlin at dberlin.org> > To: "Philip Reames" <listmail at philipreames.com>, "Davide Italiano" > <davide at freebsd.org>, "Chandler Carruth" <chandlerc at gmail.com> > Cc: "Chris Sakalis" <chrissakalis at gmail.com>, "David Majnemer" >