This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Measuring gcc optimizations: are they well balanced?


There were a lot of misunderstandings in the replies to my query.
I thought that the context (the bug code) was known, since it passed here
in this discussion group.
I mailed a lengthy message answering, but it came back saying 'bugs-gcc:
user unknown'. I had many other things to do and didn't resend it.

Then I found another problem with the gcc optimizer (the code bloat
because of stack manipulations, and mailed it to gcc-bugs, and somebody
at cygnus (Mr Law) answered asking for examples. I sent him the examples

The stand now is clearer: I have used another benchmark program to measure
the speed of gcc vs lcc, a scientific calculator written by Grenoble
University in France, called gp. This is a "mathcad" type of system, doing
intensive scientific type calculations. I used to be 10% worst than gcc,
but with the new version, this difference has dropped to 3% only. I have
the same speed as the last version of gcc I have, the new version is 3%
faster.

True, I have improved my compiler, and I now routinely allocate 3
registers for register variables automatically. But this is not really a
personal achievement, since I think the gcc generated code could be
considerable faster. One of the main culprits of gcc's slowdown are the
stack manipulations: 10% code bloat + hundreds and hundreds of processor
stalls when doing
	addl	$32,%esp
	addl	$-8,%esp
etc etc. I have found sequences of up to four of this instructions in a
single run. This means 3 forced processor stalls. 

I am telling you this not because I want to prove something, but because
if I wrote a debugger for this compiler, it should rather work well. All
this activity has costed me a lot of time, that I am contributing freely
for this project.

Please answer about the bug. Is it corrected?

Thanks in advance for your time.

P.S. all the benchmarks are in lcc's web page The figures should be much
better for me now, but I didn't update it, waiting that this bugs go away.

PP.SS. Horst says that lcc has no register variables. True, but I am
speaking of lcc-win32 here. And that one has register variables since
several years.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]