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