[LLVMdev] dragonegg svn benchmarks

[Jack Howarth]

On Wed, Oct 12, 2011 at 09:40:53AM +0200, Duncan Sands wrote:
> Hi Chris,
>
>>> PS: With -fplugin-arg-dragonegg-enable-gcc-optzns the LLVM optimizers are run at
>>> the following levels:
>>>
>>> Command line option      LLVM optimizers run at
>>> -------------------      ----------------------
>>>          -O1              tiny amount of optimization
>>>      -O2 or -O3                      -O1
>>>      -O4 or -O5                      -O2
>>>      -O6 or better                   -O3
>>
>> Hi Duncan,
>>
>> Out of curiosity, why do you follow this approach?  People generally use -O2 or -O3.  I'd recommend switching dragonegg to line those up with whatever you want people to use.
>
> note that this is done only when the GCC optimizers are run.  The basic
> observation is that running the LLVM optimizers at -O3 after running the
> GCC optimizers (at -O3) results in slower code!  I mean slower than what
> you get by running the LLVM optimizers at -O1 or -O2.  I didn't find time
> to analyse this curiosity yet.  It might simply be that the LLVM inlining
> level is too high given that inlining has already been done by GCC.  Anyway,
> I didn't want to run LLVM at -O3 because of this.  The next question was:
> what is better: LLVM at -O1 or at -O2?  My first experiments showed that
> code quality was essentially the same.  Since at -O1 you get a nice compile
> time speedup, I settled on using -O1.  Also -O1 makes some sense if the GCC
> optimizers did a good job and all that is needed is to clean up the mess that
> converting to LLVM IR can produce.  However later experiments showed that -O2
> does seem to consistently result in slightly better code, so I've been thinking
> of using -O2 instead.  This is one reason I encouraged Jack to use -O4 in his
> benchmarks (i.e. GCC at -O3, LLVM at -O2) - to see if they show the same thing.

Duncan,
   My preliminary runs of the pb05 benchmarks at -O4, -O5 and -O6 using
-fplugin-arg-dragonegg-enable-gcc-optzns didn't show any significant run time
performance changes compared to -fplugin-arg-dragonegg-enable-gcc-optzns -O3. 
I'll rerun those and post the tabulated results this weekend. I am using
-ffast-math -funroll-loops as well in the optimization flags. Perhaps I should
repeat the benchmarks without those flags.
   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.
              Jack
>
> Ciao, Duncan.
>
> PS: Dragonegg is a nice platform for understanding what the GCC optimizers
> do better than LLVM.  It's a pity no-one seems to have used it for this.