stupid.c, rip

Jim Wilson wilson@cygnus.com
Fri Jul 16 18:42:00 GMT 1999


In article < 19990716161559.A28371@cygnus.com > 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
gone.

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

Jim



More information about the Gcc-patches mailing list