Re: Use-and-clobber insns and some ancient combine.c code

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Thu, 2004-06-17 at 17:08, Ulrich Weigand wrote:
> Richard Earnshaw wrote:
> 
> > CLOBBER is used to indicate that a value is destroyed by the insn, but
> > it doesn't say precisely when this happens.  In the case of hard
> > registers we have to be conservative, because there is no way to convey
> > the equivalent of an early-clobber operand (a value that is destroyed
> > before all the other inputs have been processed).
> 
> I had not been aware of this interpretation of CLOBBER.  This is
> unfortunate, as it appears to make the use of use-and-clobber
> type patterns unfeasible ...
> 
> Has it always been that way?  The documentation appears a bit ambiguous
> on that point, e.g.:
> 
>  When a @code{clobber} expression for a register appears inside a
>  @code{parallel} with other side effects, the register allocator
>  guarantees that the register is unoccupied both before and after that
>  insn.  However, the reload phase may allocate a register used for one of
>  the inputs unless the @samp{&} constraint is specified for the selected
>  alternative (@pxref{Modifiers}).
> 
> These two sentences appear to directly contradict each other.

I don't think they do.

Note firstly that this is strictly talking about the behaviour of the
register allocator, not of combine, but we can still infer usefully from
it.

The way I read the above is that the clobber poses two restrictions on
the register allocator, a pre and a post condition.  However, the pre
condition can be lifted unless the constraint string has an '&' in the
selected alternative.

Now in your case, we aren't talking about pseudos being allocated, we
are talking about a hard register, so there is no constraint string. 
Since there isn't, combine has to act conservatively (it can't rely on
the register allocator to fix things up) and must therefore assume that
the value *might* be clobbered early.

R.