On Mon, 25 May 2009, Chris Lattner wrote:
On May 13, 2009, at 5:26 AM, Duncan Sands wrote:
Hi Richard,
-mpc64 sets the x87 floating point control register to not use the 80bit
extended precision. This causes some x87 floating point operations
to operate faster and there are no
On May 13, 2009, at 5:26 AM, Duncan Sands wrote:
Hi Richard,
-mpc64 sets the x87 floating point control register to not use the
80bit
extended precision. This causes some x87 floating point operations
to operate faster and there are no issues with the extra roundings
you
get when
On 2009-05-25 12:53:49 -0700, Chris Lattner wrote:
On May 13, 2009, at 5:26 AM, Duncan Sands wrote:
-mpc64 sets the x87 floating point control register to not use the
80bit extended precision. This causes some x87 floating point
operations to operate faster and there are no issues with the
Vladimir Makarov wrote:
People are complaining about GCC compilation speed and
of course we should work on its speedup. But GCC is not so bad, for
example SUN Studio compiler is almost 2 times slower than GCC.
Well, outside of these comparisons, I often completely flatten my
colleagues (at
3. Your SPEC FP benchmarks tell me two things: GCC 4.4's fortran support is
dramatically better than 4.2's (which llvm 2.5 uses), and your art/mgrid
hacks apparently do great stuff :).
Something like the art hack is in ipa-struct-reorg, but it is not
enabled at any level. If gcc
Joseph S. Myers jos...@codesourcery.com writes:
On Tue, 12 May 2009, Chris Lattner wrote:
1. I have a hard time understanding the code size numbers. Does 10% mean
that
GCC is generating 10% bigger or 10% smaller code than llvm?
I have a different comment on the code size numbers: could
On Wed, May 13, 2009 at 09:33:20AM +0200, Andi Kleen wrote:
Joseph S. Myers jos...@codesourcery.com writes:
On Tue, 12 May 2009, Chris Lattner wrote:
1. I have a hard time understanding the code size numbers. Does 10% mean
that
GCC is generating 10% bigger or 10% smaller code than
Andi Kleen wrote:
Joseph S. Myers jos...@codesourcery.com writes:
On Tue, 12 May 2009, Chris Lattner wrote:
1. I have a hard time understanding the code size numbers. Does 10% mean
that
GCC is generating 10% bigger or 10% smaller code than llvm?
I have a different comment on the code
From looking http://vmakarov.fedorapeople.org/spec/I2Size32.png it does
not look that bad at all. For SpecFP it is different, but code size is
The code size seems to be much worse than LLVM at least, unless
I misread the graphs.
Also my comment was in regard of the suggestion to try -Os --
Hi,
Sorry, I missed to mention that I used an additional option -mpc64 for
32-bit GCC4.4. It is not possible to generate SPECFP2000 expected
results by GCC4.4 without this option. LLVM does not support this
option. And this option can significantly improve the performance. So
32-bit
On Wed, May 13, 2009 at 1:41 PM, Andi Kleen a...@firstfloor.org wrote:
Rather, we should seriously understand what caused the compilation time
jump in 4.2, and whether those are still a problem. We made a good job
in 4.0 and 4.3 offsetting the slowdowns from infrastructure changes with
Steven Bosscher wrote:
On Wed, May 13, 2009 at 1:41 PM, Andi Kleen a...@firstfloor.org wrote:
Rather, we should seriously understand what caused the compilation time
jump in 4.2, and whether those are still a problem. We made a good job
in 4.0 and 4.3 offsetting the slowdowns from
On Wed, May 13, 2009 at 1:51 PM, Duncan Sands
duncan.sa...@math.u-psud.fr wrote:
Hi,
Sorry, I missed to mention that I used an additional option -mpc64 for
32-bit GCC4.4. It is not possible to generate SPECFP2000 expected
results by GCC4.4 without this option. LLVM does not support this
On Wed, 13 May 2009, Richard Guenther wrote:
-mpc64 sets the x87 floating point control register to not use the 80bit
extended precision. This causes some x87 floating point operations
to operate faster and there are no issues with the extra roundings you
get when storing an 80bit precision
Hi Richard,
-mpc64 sets the x87 floating point control register to not use the 80bit
extended precision. This causes some x87 floating point operations
to operate faster and there are no issues with the extra roundings you
get when storing an 80bit precision register to a 64bit memory
Andi Kleen wrote:
From looking http://vmakarov.fedorapeople.org/spec/I2Size32.png it does
not look that bad at all. For SpecFP it is different, but code size is
The code size seems to be much worse than LLVM at least, unless
I misread the graphs.
Not really, see
Paolo Bonzini wrote:
Rather, we should seriously understand what caused the compilation time
jump in 4.2, and whether those are still a problem. We made a good job
in 4.0 and 4.3 offsetting the slowdowns from infrastructure changes with
speedups from other changes; and 4.4 while slower than
Paolo Bonzini wrote:
Rather, we should seriously understand what caused the compilation time
jump in 4.2, and whether those are still a problem. We made a good job
in 4.0 and 4.3 offsetting the slowdowns from infrastructure changes with
speedups from other changes; and 4.4 while slower
On Wed, May 13, 2009 at 05:42:03PM +0200, Jan Hubicka wrote:
Paolo Bonzini wrote:
Rather, we should seriously understand what caused the compilation time
jump in 4.2, and whether those are still a problem. We made a good job
in 4.0 and 4.3 offsetting the slowdowns from infrastructure
On May 13, 2009, at 4:51 AM, Duncan Sands wrote:
Hi,
Sorry, I missed to mention that I used an additional option -mpc64
for
32-bit GCC4.4. It is not possible to generate SPECFP2000 expected
results by GCC4.4 without this option. LLVM does not support this
option. And this option can
A few people asked me to do a new comparison of GCC releases and LLVM as
the new GCC release and LLVM were out recently.
You can find the comparison on http://vmakarov.fedorapeople.org/spec/
The comparison for x86 (32-bit mode) was done on Pentium4 and for
x86_64 (64-bit mode) on Core I7.
On May 12, 2009, at 6:56 AM, Vladimir Makarov wrote:
A few people asked me to do a new comparison of GCC releases and
LLVM as the new GCC release and LLVM were out recently.
You can find the comparison on http://vmakarov.fedorapeople.org/spec/
The comparison for x86 (32-bit mode) was done
Chris Lattner wrote:
On May 12, 2009, at 6:56 AM, Vladimir Makarov wrote:
A few people asked me to do a new comparison of GCC releases and LLVM
as the new GCC release and LLVM were out recently.
You can find the comparison on http://vmakarov.fedorapeople.org/spec/
The comparison for x86
On Tue, 12 May 2009, Chris Lattner wrote:
1. I have a hard time understanding the code size numbers. Does 10% mean that
GCC is generating 10% bigger or 10% smaller code than llvm?
I have a different comment on the code size numbers: could we have
comparisons of code size for -Os rather than
Joseph S. Myers wrote:
On Tue, 12 May 2009, Chris Lattner wrote:
1. I have a hard time understanding the code size numbers. Does 10% mean that
GCC is generating 10% bigger or 10% smaller code than llvm?
I have a different comment on the code size numbers: could we have
comparisons
On May 12, 2009, at 11:05 AM, Vladimir Makarov wrote:
Chris Lattner wrote:
On May 12, 2009, at 6:56 AM, Vladimir Makarov wrote:
A few people asked me to do a new comparison of GCC releases and
LLVM as the new GCC release and LLVM were out recently.
You can find the comparison on
Vladimir Makarov wrote:
Chris Lattner wrote:
2. You change two variables in your configurations: micro
architecture and pointer size. Would you be willing to run x86-32
Core i7 numbers as well? LLVM in particular is completely untuned
for the (really old and quirky) netburst architecture,
It would also be very interesting to include LLVM's LTO support, which gives
a pretty dramatic win on SPEC. However, I don't know how difficult it is to
use on linux (on the mac, you just pass -O4 at compile time, and everything
works). I've heard that Gold has a new plugin to make LTO
On Tue, May 12, 2009 at 7:45 PM, Chris Lattner clatt...@apple.com wrote:
2. You change two variables in your configurations: micro architecture and
pointer size. Would you be willing to run x86-32 Core i7 numbers as well?
LLVM in particular is completely untuned for the (really old and
29 matches
Mail list logo
