Re: Some statement counts for gcc

[Zack Weinberg <zack at codesourcery dot com>]

On Mon, Aug 26, 2002 at 08:18:15AM -0500, Brad Lucier wrote:
> 
> The problem is that gcc's fp code generator on x87 is broken enough that
> you can get different results for the same expression, hence the use
> of the simulator which does not use extended-precision arithmetic
> by default.

Right.

>  I'm not really sure that the simulator is unreasonably slow.

33% of user time spent in branch prediction seems like something worth
at least looking at, to me.

> > If I remember correctly this code has a very complicated flow graph,
> > and branch prediction may not help much; perhaps the right thing is
> > to detect code like this and disable that optimization.
> 
> This has been the response to several of my recent observations about
> gcc's algorithms, etc.  I'd prefer that if there are problems they be
> fixed rather than papered over by a -fbrad's_code_don't_optimize flag.

In general I agree with you.  However, do I remember correctly that
this is the inner loop of a threaded (Forth sense) interpreter?  Lots
of tiny blocks with computed-goto edges both in and out?  There really
isn't much good branch prediction can do on code like that.

> Although the GC statistics indicate not much memory use, this code took up
> to 3.8 GB of swap when running.

Treat the GC statistics with a pile of salt; they only count data
still live at end of compilation.  Also, I think ra.c has a lot of
local data allocated with xmalloc, which GC doesn't see at all.

zw