Re: Combine error?

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

  In message <200003221223.MAA25613@cam-mail2.cambridge.arm.com>you write:
  > We always combine the earlier into the later; in fact, combine won't allow 
  > the merge if it can't effectively relocate the insns it is combining to be 
  > consecutive at the later position (it doesn't actually move them of 
  > course, it just checks that such a transformation would be legal).
OK.  I wasn't sure and didn't have time to check the sources :-)

  > The fact that combine always puts the result of a merge at the target does 
  > mean that we sometimes miss potential recombinations; for example
  > 
  > i1:  (set r1 plus (r2, r3))
  > 
  > i2:  (set r2 plus (r2, const 1))
  > 
  > i3:  (set r4 plus (r1, const 5))
  > 
  > We cannot at present combine i1 and i3 because i1 cannot be "moved" after 
  > i2 (since r2 is updated).  We could, but don't, merge i1 and i3 and place 
  > them before i2; but at present combine doesn't know how to do this.  Even 
  > if we did this, then provided we kept the shell of i3 as the result; any 
  > log_links pointing to it would still point to the setter insn.
Right. I think Michael Hayes has mentioned similar cases where we're
missing opportunities for insn combination.  The question is can we safely
and cleaning change combine to handle both?

Having combine work on SSA form might provide the functionality we need --
r2 in i2 would be renamed to a new register which removes the problamtic
dependency between i1 and i2.


  > I think the problem only occurs with post_inc/dec type adjustments.  In 
  > this case we have something like:
[ ... ]
Got it.

  > Which of course, leads to a possible solution to our problem of updating 
  > i4:  If, as part of creating the auto_inc we first reorder the stream as
  > 
  > i1: (set r1 mem(r2))
  > 
  > i3: (set r2 plus (r2, const 4))
  > 
  > i2: (xxx)
  > 
  > i4: (xxx (r2)) LOG_LINK (i3)
  > 
  > and then combine, but put the result in i3, we get:
  > 
  > i1: (dead)
  > 
  > i3: (set r1 mem(post_inc(r2)))
  > 
  > i2: (xxx)
  > 
  > i2: (xxx (r2) LOG_LINK (i3)
  > 
  > and our log_link still points to the correct setter.
Interesting.  However, don't you have to go find any LOG_LINK that points
to i1 and redirect it to i2?  Consider the next user of the value in r1.

jeff