On Tue, 5 May 2009, Mark Mitchell wrote:
> I personally think relying on MPC is a reasonable choice, given the fact
> that (as you say) the language specifications do in some cases require
> support for these kinds of manipulations of complex numbers at compile-time.
>
> In the past, however, othe
"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
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?
>
Thanks Kaveh for taking care of this. The Fortran front-end will
really benefit from the use of MPC. Regarding your options, #1 seems
the most reasonable to me; I'm forwarding to the Fortran list to hear
to opinion of Fortran maintainers.
FX
I have ported gcc4.0.2 to 32bit RISC chip. But internal compiler
error happened: in reload_combine_note_use, at postreload.c:1093 . I
tracked the code with insight. error occurred in "CASE REG", when the
register number is larger than FIRST_PSEUDO_REGISTER. Does this mean
the reload register allo
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
Kaveh R. GHAZI wrote:
> 1. Consider MPC as an optional library now, install all the code and make
> it hard-required only when all the complex math functions are made
> available in a future released version of the library or sometime in
> stage3, whichever is first.
> I prefer optio
daniel tian wrote:
> I have ported gcc4.0.2 to 32bit RISC chip. But internal compiler
> error happened: in reload_combine_note_use, at postreload.c:1093 . I
> tracked the code with insight. error occurred in "CASE REG", when the
> register number is larger than FIRST_PSEUDO_REGISTER. Does this me
> 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-
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
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: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
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
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
Andrew Haley wrote:
> Did you try my list of things to lift out? I don't think there will be any
> interdependencies; the only problem might be that the reduction is not enough.
Hi Andrew,
I've had a quick hack at it now, and it's not doing what I'd hoped, so
possibly I've misunderstood w
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
Could you please make a rough guess and specify
when a preliminary implementation of these C++0x
features can be expected to appear GCC4.5?
- concepts
- constructor inheritance
- constructor delegation
Is there a document which describes what are you
working on now? I'm just curious :-)
Best reg
Kaveh R. GHAZI wrote:
> 1. Consider MPC as an optional library now, install all the code and make
> it hard-required only when all the complex math functions are made
> available in a future released version of the library or sometime in
> stage3, whichever is first.
I think this is
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
Dave Korn wrote:
> So we have to
> use dlltool first to generate import libs ahead of final-link time (without
> attmepting to build a complete DLL):
>
> dlltool a1.o a2.o a3.o -D cygexample-a.dll -e libexample-a.dll.a
> dlltool b1.o b2.o b3.o -D cygexample-b.dll -e libexample-b.dll.a
> dlltool c1
> 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
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
Dave Korn wrote:
> Andrew Haley wrote:
>
>> Did you try my list of things to lift out? I don't think there will be any
>> interdependencies; the only problem might be that the reduction is not
>> enough.
>
> Hi Andrew,
>
> I've had a quick hack at it now, and it's not doing what I'd hope
Andrew Haley wrote:
> Dave Korn wrote:
>> Andrew Haley wrote:
>>
>>> Did you try my list of things to lift out? I don't think there will be any
>>> interdependencies; the only problem might be that the reduction is not
>>> enough.
>> Hi Andrew,
>>
>> I've had a quick hack at it now, and it'
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
Jamie Prescott schrieb:
Thank you Andrew, I wasn't aware of that. Will be going that way.
Just out of curiosity, was there something flawed in the way I took before?
Meaning, could have been done that way, but my code was wrong somewhere?
- Jamie
- Original Message
From: Andrew Pins
> >> On Mon, May 11, 2009 at 4:45 PM, Jamie Prescott wrote:
> >>
> >>> Hi!
> >>> I wanted to add finer (one per) register subclasses, so that I can more
> finely
> >> control
> >>> the register placement inside the inline assembly.
> >>
> >> You don't need that.
> >> You can just use asm("reg
Jamie Prescott schrieb:
On Mon, May 11, 2009 at 4:45 PM, Jamie Prescott wrote:
Hi!
I wanted to add finer (one per) register subclasses, so that I can more
finely
control
the register placement inside the inline assembly.
You don't need that.
You can just use asm("registername") on v
Ok, for the i386 port, I use uint32_t instead of uint64_t because
otherwise the assembly code generated is a bit complicated (I'm on a
32 bit machine).
The tree dump from final_cleanup are the same for the goo function:
goo (i)
{
:
return data[i + 13] + data[i];
}
However, the first RTL dump
Jamie Prescott wrote:
Thank you Paolo, I'll take a look at it.
Is there a reason why the fcmp insn was dropped with such implementation?
The code that optimizes away redundant cc0 compares is in final.c, in
final_scan_insn(). It is about line 2310 in my tree, near the comment
"Check for redu
- Original Message
> From: Jim Wilson
> To: Jamie Prescott
> Cc: Paolo Bonzini ; gcc@gcc.gnu.org
> Sent: Wednesday, May 13, 2009 6:15:07 PM
> Subject: Re: Code generation problem with optimizations enabled
>
> Jamie Prescott wrote:
> > Thank you Paolo, I'll take a look at it.
> > Is th
Jamie Prescott wrote:
enum reg_class
{
NO_REGS = 0,
GENERAL_REGS,
X_REGS,
R0_REG, R1_REG, R2_REG, R3_REG,
The only obvious thing I notice is that you have the largest classes
first. The docs say to put the smaller classes first. The compiler
always assumes th
Thank you for your advice.
Yes. I checked the MD file and relative machine.h/.c, there are some
places which call the ''force_reg' unconditionally. I modified the it
in "movm" insn pattern, the error still exists. And I also check the
mips/arm, they also call 'force_reg' unconditional in some plac
34 matches
Mail list logo
