I think I found a bug in the optimizer...

[Mark Grosberg]

On Sun, 27 Feb 2000, Zack Weinberg wrote:

> To follow up: I kicked out everything else in memory and let the
> compile run to completion.  Here's the statistics:
> 
>  __strcpy_small __strcspn_c1 __strcspn_c2 __strcspn_c3 __strspn_c1
>  __strspn_c2 __strspn_c3 __strpbrk_c2 __strpbrk_c3 __strtok_r_1c
>  __strsep_1c __strsep_2c __strsep_3c __strsep_g get_unix_info 
>  {GC 357018k -> 9480k in 0.310}
> time in parse: 36.840000 (74%)
> time in jump: 6.060000 (12%)
> [all other passes <2% each]
> 
> 3:10.22 - 45.03u, 4.45s, 26% - 80192/230866
> 
> 357018k is just under 349 Mb of core - which is far too much.  But
> note that it all got thrown away on the very first GC pass; I doubt
> the mess ever even got to the RTL level.

This is still too much memory. CC1 should do something to prune things as
it goes. Not that this wasn't caused by the evil GLIBC strcpy(), but the
compiler shouldn't let things get that big from a few lines of code.
 
> The sad part is, the assembly dump at -O2 is identical with and
> without -D__NO_STRING_INLINES.

Hehe. oh well. It's not like the performance difference could be measured
in my AMC compiler anyhow. The one hot-spot is already pretty optimal (on
everything except HP's PA-RISC since call via function pointer requires a
millicode jump)...

L8r,
Mark G.