[LLVMdev] Indexed Load and Store Intrinsics - proposal

[dag at cray.com]

"Demikhovsky, Elena" <elena.demikhovsky at intel.com> writes:

> Hi David, 
>
>
>>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.
> [Demikhovsky, Elena] From the site:
> The ‘ptrtoint‘ instruction converts the pointer or a vector of
> pointers value to the integer (or vector of integers) type ty2.

Yep, found it after llvm.org came back up.  :)

>>> Scale: a compile time constant 1, 2, 4 or 8.
>
>>This seems a bit too Intel-focused.  Why not allow arbitrary scales?
>> Or alternatively, eliminate the Scale and do a vector multiply on
>> VectorOfIndices.  It should be simple enough to write matching
>> TableGen patterns.  We do it now for the x86 memop stuff.
> [Demikhovsky, Elena] As I wrote to Nadav, may be two intrinsics will
> be more general. I'm just looking at usage model. If the index is a
> pointer, scale = 1, base = 0. If it is an index inside array, scale
> covers all basic types from char to double.
> Do you think that 2 intrinsics will be less-Intel-focused?
> (1) non-zero base and vector of indices (index is relative to base)
> and implicit scale based on element type.
> (2) without base, without scale, just vector of pointers

I don't really have an opinion as to one or two intrinsics as long as
the vector-of-pointers idiom is supported.  Does making the scaling
implicit hide optimization opportunities on architectures that don't
have instructions that automatically scale?  I don't know if there are
any architectures supporting gather/scatter that don't auto-scale but I
can imagine such architectures.  I'm just throwing out things to think
about.

I usually tend toward making everything explicit, meaning the scaling
would be done as a multiply feeding the gather/scatter intrinsic, but
that's just personal preference.  I don't have strong data to argue one
way or the other.

                              -David