Re: Q's about use of is_gimple_reg_rhs/is_gimple_tmp_var

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    True, but I wouldn't bother, because of ...

    > I'm not sure how useful that is since the copy propagator ought to do
    > the right thing in the case you're considering.

    ... this.  If the copy propagator doesn't get this case, we try and fix
    the bug.  Let's avoid early micro optimizations.

I wasn't originally discussing this as an optimization, but I'm not sure
I agree with the principle you are advocating here.

Ignoring this particular case for the moment, if we have a situation where
it's relatively easy to generate more optimal code, I disagree that we
shouldn't bother with that just because an optimizer should improve it later.
There are a number of reasons for this.

For one, it wastes memory and time to generate trees just to have them
simplified later.  For another, having something more optimal earlier may
make it easier for other optimization phases to see what's going on.

That's why the history of GCC has been to do optimizations at all levels and
as often as possible.  It's tempting to say "we have a very good optimizer,
so it doesn't matter how much junk a front end emits since we can clean it up
later", but that leads to a tremendous amout of bloat and somehow the
optimizers are never able to clean it up.  For example, if that principle
were true it would be impossible for the tree-ssa optimizations to ever
produce worse code than pre tree-ssa because the RTL optimizers should have
been able to clean up any pessimizations.  Of course, they can't in all cases
and I don't believe the tree-ssa optimizers will be fundamentally different
in this regard: the less junk you give them, the better the resulting output.

There are indeed a number of optimizations that are best down downstream as
well as optimizations that are best done very high up in the front end.

But if we have an easy opportunity to do something higher up that will avoid
later work, we should take it.  These "early micro-optimizations", as you
call them, have been a major part of GCC's success in the past, and I believe
will continue to have that role in the future.