[LLVMdev] Indexed Load and Store Intrinsics - proposal

Tue Dec 23 17:48:53 PST 2014

----- Original Message -----
> From: "Xinmin Tian" <xinmin.tian at intel.com>
> To: "Hal Finkel" <hfinkel at anl.gov>, "Ayal Zaks" <ayal.zaks at intel.com>
> Cc: dag at cray.com, "Robert Khasanov" <robert.khasanov at intel.com>, llvmdev at cs.uiuc.edu
> Sent: Tuesday, December 23, 2014 7:36:44 PM
> Subject: RE: [LLVMdev] Indexed Load and Store Intrinsics - proposal
> 
> For non-zero case,  most of time (e.g. a[i]), the "base" is uniform,

Agreed.

> the property helps to identify and perform neighboring
> gather/scatter optimizations in some applications. If the
> information is preserved, later, it may not easy to recover this
> "uniform" information.

I don't understand what you mean. Why do you feel the information will be difficult to recover later from vector GEPs feeding the scatter/gather intrinsics?

 -Hal

>  Non-zero case is not designed only for x86,
> basically, it helps to preserve certain program information.
> 
> Thanks,
> Xinmin
> 
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu
> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel
> Sent: Tuesday, December 23, 2014 5:17 PM
> To: Zaks, Ayal
> Cc: dag at cray.com; Khasanov, Robert; llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] Indexed Load and Store Intrinsics - proposal
> 
> ----- Original Message -----
> > From: "Ayal Zaks" <ayal.zaks at intel.com>
> > To: "Philip Reames" <listmail at philipreames.com>, dag at cray.com,
> > "Elena
> > Demikhovsky" <elena.demikhovsky at intel.com>
> > Cc: "Robert Khasanov" <robert.khasanov at intel.com>,
> > llvmdev at cs.uiuc.edu
> > Sent: Monday, December 22, 2014 8:05:43 AM
> > Subject: Re: [LLVMdev] Indexed Load and Store Intrinsics - proposal
> > 
> > > Why shouldn't the IR representation simply be a load from a
> > > vector
> > > of arbitrary pointers?
> > 
> > Such a load could indeed serve as a general form of a gather or
> > scatter. As Elena responded, we can propose two distinct
> > intrinsics:
> > one with a vector of pointers, and another with (non-zero) base, a
> > vector of indices, and a scale implicitly inferred from the element
> > type.
> > 
> > The motivation for the latter stems from vectorizing a load or
> > store
> > to "b[i]", where b is invariant. Broadcasting b and using a vector
> > gep
> > to feed a vector of pointers, to be pattern matched and folded
> > later,
> > may work.
> 
> I would like you to explore this direction, where we use a vector GEP
> and the intrinsic simply takes a vector of pointers. The backend
> should pattern-match this as appropriate. I see no reason why we
> can't make this work, especially because we don't have any real uses
> of vector GEPs now, so we can *define* the canonical optimized form
> of them to be conducive to the kind of pattern matching we'd like to
> perform in the backends.
> 
> This, I imagine, will require some additional infrastructure work.
> Currently, GEPs, including vector GEPs, are expanded very early
> during SDAG building, and the form produced may not be appropriate
> for reliable pattern matching during later lowering phases. The way
> this is done is not set in stone, however, and we can certainly
> change it (including via the introduction of new SDAG nodes) to keep
> the necessary information together in compact form.
> 
> Thanks again,
> Hal
> 
> > The alternative intrinsic proposed keeps b scalar and uses a vector
> > of
> > indices for i. In any case, it's important to recognize such common
> > patterns, at-least for x86, so could deserve an x86 intrinsic. But
> > it's a general pattern that could potentially serve other
> > implementations; any other gathers to consider atm?
> > 
> > Documentation indeed needs to be provided.
> > 
> > Ayal.
> > 
> > 
> > -----Original Message-----
> > From: llvmdev-bounces at cs.uiuc.edu
> > [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Philip Reames
> > Sent: Sunday, December 21, 2014 20:25
> > To: dag at cray.com; Demikhovsky, Elena
> > Cc: Khasanov, Robert; llvmdev at cs.uiuc.edu
> > Subject: Re: [LLVMdev] Indexed Load and Store Intrinsics - proposal
> > 
> > 
> > On 12/18/2014 11:56 AM, dag at cray.com wrote:
> > > "Demikhovsky, Elena" <elena.demikhovsky at intel.com> writes:
> > >
> > >> Semantics:
> > >> For i=0,1,…,N-1: if (Mask[i]) {*(BaseAddr +
> > >> VectorOfIndices[i]*Scale)
> > >> = VectorValue[i];}
> > >> VectorValue: any float or integer vector type.
> > >> BaseAddr: a pointer; may be zero if full address is placed in
> > >> the
> > >> index.
> > >> VectorOfIndices: a vector of i32 or i64 signed or unsigned
> > >> integer
> > >> values.
> > > What about the case of a gather/scatter where the BaseAddr is
> > > zero
> > > and the indices are pointers?  Must we do a ptrtoint?  llvm.org
> > > is
> > > down at the moment but I don't think we currently have a vector
> > > ptrtoint.
> > I would be opposed to any representation which required the
> > introduction of ptrtoint casts by the vectorizer.  If it were the
> > only
> > option available, I could be argued around, but I think we should
> > try
> > to avoid this.
> > 
> > More generally, I'm somewhat hesitant of representing a scatter
> > with
> > explicit base and offsets at all.  Why shouldn't the IR
> > representation
> > simply be a load from a vector of arbitrary pointers?
> >  The backend can pattern match the actual gather instructions it
> > supports and scalarize the rest.  The proposal being made seems
> > very
> > specific to the current generation of x86 hardware.
> > 
> > p.s. Where is the documentation for the existing mask load
> > intrinsics?
> > I can't find it with a quick search through the LangRef.
> > 
> > Philip
> > 
> > 
> > 
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > ---------------------------------------------------------------------
> > Intel Israel (74) Limited
> > 
> > This e-mail and any attachments may contain confidential material
> > for
> > the sole use of the intended recipient(s). Any review or
> > distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> > 
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > 
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory