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
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 wit
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 storing
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
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 sign
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 inf
> 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
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 4.3
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 http://vmakarov.fedo
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 loc
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 precisi
On Wed, May 13, 2009 at 1:51 PM, 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 op
Steven Bosscher wrote:
> On Wed, May 13, 2009 at 1:41 PM, Andi Kleen 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 change
On Wed, May 13, 2009 at 1:41 PM, Andi Kleen 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 othe
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-
> 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 --
Andi Kleen wrote:
> "Joseph S. Myers" 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 nu
On Wed, May 13, 2009 at 09:33:20AM +0200, Andi Kleen wrote:
> "Joseph S. Myers" 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?
>
"Joseph S. Myers" 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 we have
> co
>> 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
On Tue, May 12, 2009 at 7:45 PM, 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" a
> 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 tr
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,
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 http://vmak
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 o
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
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 (32
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 o
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.
S
29 matches
Mail list logo
