[LLVMdev] dragonegg svn benchmarks

Jack Howarth howarth at bromo.med.uc.edu
Thu Oct 13 07:05:10 PDT 2011


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, 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.



More information about the llvm-dev mailing list