This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Added LLVM 1.2 to nightly SPEC comparison runs
- From: Chris Lattner <sabre at nondot dot org>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 8 Apr 2004 10:46:07 -0500 (CDT)
- Subject: Re: Added LLVM 1.2 to nightly SPEC comparison runs
On Thu, 8 Apr 2004, Diego Novillo wrote:
> On Thu, 2004-04-08 at 11:18, Chris Lattner wrote:
>
> > How did you build LLVM?
> >
> $ ../llvm/configure --with-llvmgccdir=/home/cygnus/dnovillo/llvm/1.2/cfrontend/x86/llvm-gcc --enable-spec2000=/notnfs/dnovillo/spec2000 --enable-optimized --prefix=/home/cygnus/dnovillo/llvm/1.2
> > By default it compiles in debug mode and
> > extensive assertion checking that are useful for development (think
> > "checking enabled"++). If you build the tree with 'make
> > ENABLE_OPTIMIZED=1' you should get the binaries in the llvm/tools/Release
> > instead of the llvm/tools/Debug directory.
Okay, that should do it as well. :)
> > It is also worth checking to
> > make sure that the C front-end you are using is not compiled in debug
> > mode.
> >
> Dunno. I used the binaries you have in your web page. I would presume
> you build releases with --disable-checking.
I honestly have no idea. I actually doubt it, but it really isn't that
important. I'll add it to my todo list for 1.3.
> > The other, perhaps more important, thing to remember is that you are
> > asking LLVM to compile the program *twice*: first with LLVM (optimizing it
> > and emitting a C file), then with GCC to compile the gigantic C file for
> > the whole program to native code. These C files are often pretty big
> > (e.g., 966077 LOC and 42MB for 176.gcc), so that adds a substantial time
> > penalty to the compilation process.
> >
> Ah, good point. There isn't an easy way to compare compile times, then.
>
> > If you're rather wait until 1.3 is out, that's
> > also fine, it will probably be out in a couple of months or so.
> >
> I'd rather track released versions of other compilers. It makes
> comparison easier. Will 1.3 have the -Wl,-native-cbe patch that I had
> to apply to run SPEC?
Okay, that makes sense. 1.3 will definitely have the option I added for
you.
> > Do you have any idea why gcc, crafty, perlbmk and vortex are failing for
> > you? They work fine for us, so I'd like to know if there is some sort of
> > bug that is triggering for you but not us or something.
> >
> crafty miscompares. Check the SPEC log file at
> http://people.redhat.com/dnovillo/spec2000/baseline-llvm12/log/20040407/
>
> Perhaps I need some portability flags for llvm. What do you folks have
> in your spec.cfg?
Portability flags shouldn't be needed at all, past what you need to get it
working with standard GCC on X86. If you could, please apply this patch:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040405/013594.html
... as I now realized that it is probably causing the problem.
> > Do you have any code size numbers? Our inliner is currently tuned to be
> > pretty conservative, it would be interesting to see how size compares.
> >
> Ah, no. Those are not gathered anymore, sorry.
Ok, thanks.
> > Is there any interest in compiling the output of LLVM with tree-ssa?
> >
> Sure. You could target llvm to mainline after the merge.
What I was trying to say is that you can choose to compile the C code
output by LLVM with any C compiler you want. Compiling that with tree-ssa
would be interesting.
> > Also, can you change "gcc version 3.4-llvm 20030924 (experimental)" to
> > "LLVM 1.2"?
> >
> Well, yes, but the script just uses whatever 'llvmgcc --version' says.
> The page is autogenerated, so it would be overwritten the next time it's
> updated.
Ok, thanks!
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/