[LLVMdev] dragonegg svn benchmarks

[Hal Finkel]

On Thu, 2011-10-13 at 10:05 -0400, Jack Howarth wrote:
> On Thu, Oct 13, 2011 at 02:37:54PM +0200, Duncan Sands wrote:
> > Hi Jack,
> >
> >>     IMHO, the more important thing is to fish out the remaining regressions
> >> in the llvm vectorization code by defaulting -fplugin-arg-dragonegg-enable-gcc-optzns
> >> on in dragonegg svn once llvm 3.0 has branched. Hopefully this will get us wider
> >> testing of the llvm vectorization support and some additional smaller test cases
> >> that expose the remaining bugs in that code.
> >
> > turning on the GCC optimizers by default essentially means giving up on the LLVM
> > IR optimizers: one way of reading your benchmark results is that the LLVM IR
> > optimizers don't do anything useful that the GCC optimizers haven't done
> > already.  The fact that LLVM -O3 and -O2 don't produce better code than -O1
> > suggests that all that is needed is a little bit of optimization to clean up
> > the inevitable messy bits produced by the gimple -> LLVM IR conversion, but
> > that otherwise GCC already did all the interesting transforms.  Should this be
> > considered an LLVM bug or a dragonegg feature?
> >
> > An LLVM bug: if the GCC optimizers work better than LLVM's then LLVM should be
> > improved until LLVM's are better.  Turning on the GCC optimizers by default just
> > hides the weaknesses of LLVM's optimizers, and reduces the pressure to improve
> > things.
> >
> > A dragonegg feature: users want their code to run fast.  Turning on the GCC
> > optimizers results in faster code, ergo the GCC optimizers should be turned
> > on by default.  That way you get faster compile times and fast code.
> 
> Duncan,
>     My main concern is that we test the vectorization support in llvm as hard as
> possible post llvm 3.0. Considering that llvm is unlikely to get autovectorization
> support in the near term, 

I just came across this: http://www.cdl.uni-saarland.de/projects/wfv/ --
It says that it will be released in the "near future".

Also, Intel's ISPC (http://ispc.github.com/) generates vector
instructions.

[I don't have an opinion on the default dragonegg options].

 -Hal

> it seems that FSF gcc/dragonegg is the best approach
> to hunt for vectorization issues in llvm. Might we be able to split the difference
> here and create a variant of -fplugin-arg-dragonegg-enable-gcc-optzns which only
> enables a limited set of FSF gcc optimizations (like -ftree-vectorize) required
> to enable FSF gcc's autovectorization under dragonegg? For instance couldn't
> dragonegg just honor -ftree-vectorize when it or -O3 are passed as compiler flags?
>                       Jack
> 
> >
> > I have some sympathy for both viewpoints...
> >
> > Ciao, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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