llvm dev - Jul 2015 - [LLVMdev] SPMD Autovectorizer

Hi,

Are there any plans to integrate an autovectorizer for SPMD programs into
LLVM? For example, there were previous discussions about integrating the
whole function vectorizer (WFV) from Ralf Karrenberg into LLVM.

Thanks,
Zack
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150706/7acac468/attachment.html>

----- Original Message -----
> From: "Zack Waters" <zswaters at gmail.com>
> To: "llvmdev" <llvmdev at cs.uiuc.edu>
> Sent: Monday, July 6, 2015 1:03:47 PM
> Subject: [LLVMdev] SPMD Autovectorizer
> 
> 
> 
> Hi,
> 
> Are there any plans to integrate an autovectorizer for SPMD programs
> into LLVM? For example, there were previous discussions about
> integrating the whole function vectorizer (WFV) from Ralf Karrenberg
> into LLVM.
> 
I don't know of any concrete plans, but this is something I'd still like
to see happen. If no one gets to it first, I may even work on it at some point.

 -Hal
> 
> Thanks,
> Zack
> _______________________________________________
> 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

On 07/06/2015 09:40 PM, Hal Finkel wrote:
> I don't know of any concrete plans, but this is something I'd still
> like to see happen. If no one gets to it first, I may even work on it
> at some point.
The pocl's kernel compiler's parallel region analysis
could also provide for a starting point. It generates parallel
loops out from the regions between barriers via static
analysis which the vectorizers then vectorize/parallelize as
they see fit for the target at hand (with assistance from
the parallel loop annotations).

The loops could even be converted (selectively) to OpenMP
parallel loops for flexible parallelization when there are
not too many work items and an SMP target has multiple cores,
etc. The point is that the way those loops are mapped to
hardware is up to other (target dependent) passes(*).

However, the current upstream version is somewhat rusty with
some known issues, and I'd like to try to find time after
the summer to clean up an experimental private version and
push it to pocl master.

Maybe that could serve as a basis for LLVM upstreaming?
Previously I've assumed that this part of the pocl kernel
compiler could not be easily upstreamed to LLVM as it's
not needed for C/C++ (and someone said other languages
such as OpenCL C are very low priority), but if there's
interest, I'd be happy to get that part upstreamed
as well.

(*) http://link.springer.com/article/10.1007/s10766-014-0320-y

BR,
-- 
--Pekka

On 6 July 2015 at 19:03, Zack Waters <zswaters at gmail.com>
wrote:
> Are there any plans to integrate an autovectorizer for SPMD programs into
> LLVM? For example, there were previous discussions about integrating the
> whole function vectorizer (WFV) from Ralf Karrenberg into LLVM.
Wouldn't OpenMP account for some of that? At least on a single
machine, could you have both parallel and simd optimisations done on
the same loop? For MPI solutions, I believe just vectorising the code
per architecture would achieve a similar goal.

What other points could be relevant, here?

cheers,
--renato

On 07/07/2015 01:32 PM, Renato Golin wrote:
> Wouldn't OpenMP account for some of that? At least on a single
> machine, could you have both parallel and simd optimisations done on
> the same loop?
The point in SPMD program description (e.g. CUDA or OpenCL C)
autovectorization is to produce something like OpenMP parallel
loops or SIMD pragmas automatically from the single thread/WI
description, adhering to its barrier synchronization semantics
etc.

That is, the output of this pass could be also converted to
OpenMP SIMD constructs, if wanted. In pocl's case the output
is simply a new kernel function (we call "work group function")
that executes all WIs using parallel loops (which can be
autovectorized more easily, or even multithreaded if seeing fit,
or both).

-- 
--Pekka