stupid.c, rip

Jim Wilson
Fri Jul 16 18:42:00 GMT 1999

In article < > you write:
>  (3) There's zero point to having two completely separate
>      register allocation passes.

I think the original point was that stupid was a lot faster, thus helping
ensure that -O0 compiles are fast.

What happens to -O0 compile times if we get rid of stupid.c?

>   (C) The needless uses are dead.

There are a lot more of them than your patch removes.  Just looking at expr.c
I see three places: store_constructor, expand_builtin_apply_args,
expand_builtin_return.  Looking at the C++ front end, there seems to be one
in fixup_result_decl in expr.c.  These are just annoyances though, these now
unnecessary USEs shouldn't cause any harm.  It will probably take us a long
time to find all of them that could be removed.

Maybe we should also get rid of obey_regdecls.  It is always !optimize, so
there doesn't seem to be any point to keeping it, especially if stupid.c is

If there isn't a serious compile-time regression, then this looks like a good
change to me.


More information about the Gcc-patches mailing list