[ slow compiles on AXP ]
> There are two killers that I know of:
> -- The bits that try to convert to conditional moves has a bad
> exponential worst case, that isn't really that uncommon in largish
> functions. Some of you may remember an example posted here some
> months ago (extracted from the X server I believe) that took > 20
> minutes to compile.
> -- Quite a bit of effort goes into figuring out how to load
> constants > |32k|.
> Aside from that, I'm pretty sure instruction scheduling is an O(n**2)
> algorithm; I've not looked at the register allocation bits.
I decided to look into this a little more, so I am compiling the kernel
right now with a profiled cpp and cc1. I am doing this under Digital Unix
since I am most confortable with the profiler over there, but I see the
same slow performance with the DU gcc that I do with linux'es, so I think
the results will be valid. Its been running about 6 hours now, but its
about done (isn't profile code slooow). I will convert the results to
html and put them on the web in the morning. If someone wants to help,
it would be interesting to profile the compiling of the kernel on an
intel based machine to see where the differences are. I have never
used the linux gprof to profile multiple executions of one program,
but I just looked at the man page, and gprof has a -s switch which looks
like it would allow for this.
I looked at the results of the profile after it had finished a few files,
and it does not look like its spending a teriffic amount of time in the
optimizer. It does spend a good bit in the parser, which I think is good
because the parser is probably easier to optimize than the code generator.
Anyway, I will have the results in the morning. I have to fix a bug in
my gprof output to html script now :-(
-- To unsubscribe: send e-mail to firstname.lastname@example.org with 'unsubscribe' as the subject. Do not send it to email@example.com
Copyright © 1995-1997 Red Hat Software. Legal notices