Re: try_replace_reg improvement

[Jeffrey A Law <law at cygnus dot com>]

  In message <19991101162414.02585@atrey.karlin.mff.cuni.cz>you write:
  > > Consider a note that had (plus (reg x) (reg y))
  > > 
  > > Assume that we determine (reg y) is always equivalent to (const_int 0))
  > > 
  > > When we call simplify_rtx on (plus (reg x) (const_int 0)) we'll hopefully
  > > get back just (reg x).  Which we can't put into a REG_EQUAL note.
  > OK.
  > How do you imagine to handle it? Try to do the replacement, simplify_rtx
  > and if the result is single register expression, burn whole insns and call
  > emit_move_insn?
I'm sorry.  I do not understand what you're trying to say here.

What I'm considering is extracting the SET_SRC for the insn, substituting
the cprop value into it, simplifying the result, then trying to recognize
the resulting insn.

We'd do something similar for the notes, except that we have to verify that
the result of simplification is not a naked (reg ... ) expression.

  > Or just to burn the note and loose information?
  > It is safe to update the REG_EQIV notes too? Or the expression there ought
  > to be independent on registers changing in the function?
There should not be REG_EQUIV notes at this stage in compilation; REG_EQUIV
notes are not supposed to appear until register allocation starts.

  > I tought it can be usefull if we modify gcse to insert values from
  >  REG_EQUAL notes > to tables too.
I doubt it's worth the time, effort or complexity.  Yes, there are cases one
can write or describe where it would be useful, but I suspect in general it
will not be useful.

It is something people can experiment with, but I wouldn't want to add that
support until it's clearly worth the pain and effort.

Even if we start putting REG_EQUAL notes into the tables, I do not think that
the addition of a REG_EQUAL note is significant enough to cause a whole new
cprop pass to run simply because the vast majority of the time we're not
going to be able to perform any additional optimizations.

It's similar to throttling global cse at one or two passes.  While later
passes may find additional optimizations, the cost in compilation time
and memory just is not worth it.

jeff