Re: [new-ra] "#if DENIS"

[Michael Matz <matz at suse dot de>]

Hi,

On 23 Jul 2003, Denis Chertykov wrote:

> No. ra_modified_insns also contain insns modified only in current pass.

Doh.  My bad ;)

> > Yes of course.  But it simply wasn't working.  The allocator crashed
> > sometimes when presented with the new or changed instructions results from
> > those later pre-reloads.
>
> Ugh. I lose your think. :(

I just wanted to say, that I disabled to actually make pre-reloads after
the first pass.  I did this, because doing pre-reloads in later passes
confused the incremental machinery to a point where inconsistent
structures were built (which later lead to abort() in sanity checks).

IIRC (it is months ago, I don't remember the specifics) the problem had to
do with new instructions emitted, or with the changed instructions, which
lead to wrong collection of register references in df.c, which then
resulted in some webs containing old register references, but not all of
the new one which were emitted by pre-reloads.

> Few mails ago I have asked "why you don't use ra_validate_change".
> I asked because only ra_validate_change can guarantee that changes will be
> valid i.e. reload or pre-reload will not be needed.

This is independend from the above point, and I think I answered that by
mentioning that I changed validate_change() to do what I wanted.

> i1 use p10
> i21 (INSN DELETED)
> i2 use stack-slot-for-p11'
>
> All insns in this case will be valid in any pass.

Do you argument that there should have been no later pre-reloads generated
anyway in later coloring rounds, because all instructions were already
basically valid?  This was definitely false, there were pre-reloads
generated.  You could also mean, that this was only a result of me using
validate_change() (the changed one), not ra_validate_change(), and I don't
remember if this was the case.  One could simply activate generation of
pre-reloads again in later passes and try a full bootstrap on x86.  I
believe that would trigger it.


Ciao,
Michael.