llvm dev - Apr 2012 - [LLVMdev] [llvm-commits] Vectors of Pointers and Vector-GEP

Hal Finkel <hfinkel at anl.gov> writes:
>> Vector-geps on the other hand are only useful in very specific
>> cases.
> At the moment, the only cases where I've seen these vectorized in the
> current implementation is where some vectorizable integer calculation
> was done and then converted into pointers used by GEPs. I am not sure
> how common this is in real code.
It is quite common in HPC codes.  It gets used for loops like this:

   for(...) {
     a[i] = b[x[i]] + c[y[i]];
   }
> Do you think we should also add vector scatter/gather loads and stores?
I'm not sure about this.  Intrisics might be good enough.  The question
comes down to how much the LLVM optimizer needs to know about them.
Alias and dependence analysis can often figure quite a bit out if they
try hard enough but that would require native IR instructions, I think.

In addition, I suspect more and more architectures are going to start
supporting G/S so a generic instruction would make the IR more portable
and we wouldn't have to reinvent the wheel for each target.

                                 -Dave

On Fri, 20 Apr 2012 13:02:29 -0500
<dag at cray.com> wrote:
> Hal Finkel <hfinkel at anl.gov> writes:
> 
> >> Vector-geps on the other hand are only useful in very specific
> >> cases.
> 
> > At the moment, the only cases where I've seen these vectorized in
> > the current implementation is where some vectorizable integer
> > calculation was done and then converted into pointers used by GEPs.
> > I am not sure how common this is in real code.
> 
> It is quite common in HPC codes.  It gets used for loops like this:
> 
>    for(...) {
>      a[i] = b[x[i]] + c[y[i]];
>    }
That makes sense.
> 
> > Do you think we should also add vector scatter/gather loads and
> > stores?
> 
> I'm not sure about this.  Intrisics might be good enough.  The
> question comes down to how much the LLVM optimizer needs to know
> about them. Alias and dependence analysis can often figure quite a
> bit out if they try hard enough but that would require native IR
> instructions, I think.
> 
> In addition, I suspect more and more architectures are going to start
> supporting G/S so a generic instruction would make the IR more
> portable and we wouldn't have to reinvent the wheel for each target.
I suppose that I favor just added support into the existing load and
store instructions. Like supporting vector GEPs, this can be done
without changing the number of instructions, and so does not cause any
binary-format incompatibilities. If we introduce a target-independent
intrinsic, it would essentially serve the same purpose, but if we then
add support into the general load/store instructions, we'd then have to
support redundant functionality.

Thanks again,
Hal
> 
>                                  -Dave


-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory

Hal Finkel <hfinkel at anl.gov> writes:
> I suppose that I favor just added support into the existing load and
> store instructions. Like supporting vector GEPs, this can be done
> without changing the number of instructions, and so does not cause any
> binary-format incompatibilities. If we introduce a target-independent
> intrinsic, it would essentially serve the same purpose, but if we then
> add support into the general load/store instructions, we'd then have to
> support redundant functionality.
Ah yes, of course.  So you're talking about having load/store accept a
vector GEP as an operand and be typed appropriately.  Yes, I think that
makes perfect sense.

                                 -Dave