[llvm-dev] [LLVMdev] LLVM loop vectorizer - changing vectorized code

C Bergström via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 13 12:31:56 PDT 2016


On Tue, Jun 14, 2016 at 3:22 AM, Alex Susu via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>   Hello, Mikhail.
>     I'm planning to do source-to-source transformation for loop
> vectorization.
>     Basically I want to generate C (C++) code from C (C++) source code:
>       - the code that is not vectorized remains the same - this would be
> simple to achieve if we can obtain precisely the source location of each
> statement;
>       - the code that gets vectorized I want to translate in C code the
> parts that are sequential and generate SIMD intrinsics for my SIMD processor
> where normally it would generate vector instructions.
>      I started looking at InnerLoopVectorizer::vectorize() and
> InnerLoopVectorizer::createEmptyLoop(). Not generating LLVM code but C/C++
> code (with the help of LLVM intrinsics) is not trivial, but it should be
> reasonably simple to achieve.
>
>     Would you advise for such an operation as the one described above?  I
> guess doing this as a Clang phase (working on the source code) is not really
> a bad idea either, since I would have better control on source code, but I
> would need to reimplement the loop vectorizer algorithm that is currently
> implemented on LLVM code.


vectorization is a coordination from high level optimizations like
loop level stuff and low level target stuff. If you are still at the
source level, how do you plan to handle the actual lowering? In that
case you'll still always be at the mercy of another piece, which may
or may not be able to handle what you've done. (In theory your
transformation could be correct, but backend just not handle it)

Having said this - why not actually work on fixing the root of the
"problem" - that being the actual llvm passes which aren't doing what
you need. This would also likely be more robust and you can maintain
control over the whole experiment (compilation flow)

I get really annoyed when reviewing papers from academics who have
used source-to-source because they thought it was "easier". Short term
short-cuts aren't likely going to produce novel results..


More information about the llvm-dev mailing list