Re: state of 3.2.1-pre: how far from release?

[Michael Matz <matz at suse dot de>]

Hi,

On Wed, 6 Nov 2002, David Edelsohn wrote:

> Michael> We also know, that (reg 929) == (plus (reg r11) 520).
>
> 	Your typos when copying the example are confusing the situation.

Bah.  Sorry ;)

> 	(reg 929) = (plus (reg r31) (const_int 520))
>
> r31 = frame pointer
>
> However, the instruction does not allow an offsettable address as the
> source, so the address sum eventually gets reloaded into a hard reg, e.g.,
> r17.

Yes, but that happens later.

> 	In other words, we eventually have
>
> 	(reg 929) = (reg r17)

No, we don't.  We have the first identity (p929 == r31+520) and then, when
reloading, for _one_ insn we have the identity
  r31+520 == r17.

>From those two it does _not_ follow, that p929 is allocated to r17 as far
as reload is concerned.  It's of course true during that insn, but it
isn't equivalent to saying "reg_renumber[929] == 17".  One reason is, that
there is no p929 that reload sees in the insn, it just reloads the
expression r31+520 into some free hardreg.  The other is (even if reload
would see p929 somewhere) that _reloads_ are not done by directly changing
the pseudo reg rtx.  Doing that would be wrong, because a pseudo without
hardreg could be reloaded into hard X in one insn, and in hardreg Y in a
different insn and X is used in some other way in the latter insn.  But as
I said this anyway isn't important here, because the insn doesn't have
_any_ p929 anymore, as far as reload is concerned.

We basically have two different effects with the same reason here.  One is
that eliminate_regs_in_insn() does not change all occurences of p929 to
the constant expression.  That's not that bad, because it could be fixed
by reload later, if the same reason wouldn't also result in
the issue in reload, that it doesn't see those other operands.

> The other pluses are implicit in the instruction because the sequence

But there is noone knowing that.  The other operands don't exist at all,
therefore it's no wonder they end up being inconsistent with each other.

> of registers is loaded from a sequence of memory addresses.
>
> Michael> As you said this works in HEAD, does anybody know if this issue really is
> Michael> fixed there, or does it simply not happen there?
>
> 	I do not see any changes in reload which would fix this.  HEAD
> seems to have complete the substitution prior to elimination.

Hmm, before elimination, or is elimination doing the right thing?  (I.e.
changing all occurences of p929)

> Is global alloc just getting this right prior to reload?

If by coincidence that pseudo _does_ get a hardreg all would have worked
out (masking the error but still), so that would be possible.


Ciao,
Michael.