[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Icarus Verilog building from CVS
On Mon, 9 Aug 2004 09:56:54 -0400
Joshua Boyd <firstname.lastname@example.org> wrote:
> On Mon, Aug 09, 2004 at 09:35:29AM +0200, Lars Segerlund wrote:
> > Well, I am running some computationally intensive code, ( CFD ), and
> > gcc 3.5 ( upcoming ) is giving a boost of up to 30 % for FORTRAN and
> > C code in some instances.
> > The 'new' gcc does have a much better optimization framework, and it
> > is really starting to show, it should fx. be able to run head to head
> > with intels compiler provided that it is supplied with a reasonable
> > set of compiler flags, ( which is an area of itself :-) ).
> This is good to hear. It doesn't yet help those of us who need a stable
> compiler though, does it?
> > SO if you look for the code generated by the 'state of the art' gcc i
> > do not believe your statement to be true, ( check out code for the sh
> > and h8 processors or the mips32 instruction set ).
> It seems to me that it is reasonable to make qualitative statements
> about a product based on it's stable releases, not it's beta or alpha
> code. Until GCC 3.5 is ready, it is far to say that GCC stinks at
> optimizing for certain platforms.
I know that there have been some issues that are only recently started to get resolved for the sh3/h8 and similar CPU's, ( there have been some noice about it on the gcc developer list ).
> > If you have any cases which can be reduced to misoptimizations please
> > post a bug report on gcc.gnu.org
> If our GCC bug is still present in 3.4, I will be reporting it. We
> currently use 3.2.1 for SH3, but are in the process of migrating.
> > If not, ( and from my opinion and experience ), I can only conider
> > your statement an ill informed opinion.
> Wait, you telling us we are ill informed because we make a statement
> about how things were quite recently? My impression is that GCC 3.4
> still isn't fully stable in some environments, AND it still isn't as
> fast as Sun and MIPS vendor compilers.
There have been a bit of discussion about different flags, since some thought the compiler generated some lousy code, when this was easily cured to the extent on going par on par with the intel compiler which I think is a good result. ( discussion on gcc.gnu.org ).
Now since you're using 3.2 I think you will find quite a lot has changed recently, I think 3.2 is capable of doing some really dumb register allocations for the sh and also some stupid things with inlining.
> Here at work I'm trying to get us moved up to 3.4 for the SH3 platform.
> You now have me very curious about trying 3.5 on this platform. We've
> been using 3.2.1 for our SH3 work, and it has a bug in it that forces us
> to use -O1 optimization.
If I were you I would probably try 3.5 from cvs on my local account, I would be a bit wary about the sh support in a release which had undergone so big changes, but I am using it right now on x86, alpha, amd64 with good results, ( I need fortran 95 thus I have to use 3.5 ), but not whitout the odd hurdle.
In my experience the 3.5 version goes between better than 3.4 and a lot of regressions in cycles :-) .... ( I always keep a working copy and one to check out :-) ).
> > ( btw. dec's compiler used to build on gcc :-) especially the openMP
> > part ), and this should give some indication of the performance of
> > gcc.
> The OpenMP part was build on gcc? But, gcc doesn't support openmp
> (unless 3.5 is adding it), to my understanding. And this is an area
> that I'm doing my best to stay abreast of developments in.
DEC had a compiler for True/Open 64 Unix bla bla bla, ( of which I have some bits and pieces lying around :-) ) which did support most of OpenMP, I checked this out as I got a bit enthused about the gomp project, ( open MP for gcc ). I think you still can find this info on the gomp site at savannah. OpenMP will not appear until after 3.5 some time in the future since it needs the optimization framework that 3.5 introduces ( tree-ssa form ), thus all developement on gomp went into first getting tree-ssa into gcc and then to take it from there.
I do believe that our different opinions stems from the slight difference of perspective of one using the compiler, and someone who is quite involved in the compiler and actively pursuing it's developement, ( thus totally blind for any blemishes that might hit the unsuspecting user :-) )....
Oh, I almost forgot there is an ongoing drive to reduce compile time performance regressions :-) ...
/ best regards, Lars Segerlund.