This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [new-ra] "#if DENIS"
- From: Denis Chertykov <denisc at overta dot ru>
- To: Michael Matz <matz at suse dot de>
- Cc: Denis Chertykov <denisc at overta dot ru>, gcc-patches at gcc dot gnu dot org
- Date: 23 Jul 2003 00:04:29 +0400
- Subject: Re: [new-ra] "#if DENIS"
- References: <Pine.LNX.4.44.0307221024590.2024-100000@wotan.suse.de>
Michael Matz <matz@suse.de> writes:
> On 21 Jul 2003, Denis Chertykov wrote:
>
> > You right. last_changed_insns and ra_modified_insns may be identical.
>
> Nearly. last_changed_insns only contain insns modified (or new) in
> the current round, i.e. it's reset each round. ra_modified_insns contains
> the cumulated information.
No. ra_modified_insns also contain insns modified only in current pass.
This is a fragment nearly before call to df_analyse inside main loop.
if (!ra_modified_insns)
ra_modified_insns = BITMAP_XMALLOC ();
else
bitmap_clear (ra_modified_insns);
>
> > > They all should be rescanned, see above. But for later passes no reloads
> > > are added, just the regclass field is set.
> >
> > It's a thing about which I have worried.
> > You have disabled changing of insns in non-first pass of pre-reload.
> > So, if pre-reload want to change insn then it's a wrong insn and
> > (probably) it can't be rescanned right. The wrong classes will be choosed
> > for pseudos (ra_refs) and wrong web->regclass will be calculated too.
>
> 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. :(
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.
I don't understand you.
Today the allocator work in the following manner.
Example:
i1 use p10 (p10 has a death right now.)
i2 use p11
p10 require CREG
p11 require CREG
Allocator want to spill p11. I'm prefer to have a remaining move to
avoid overconstraining.
i1 use p10
i21 def p11' use p11
i2 use p11'
We have a probability that now graph will be colored. If not then i21
will be removed by coalesce_spill_slot if possible.
i1 use p10
i21 (INSN DELETED)
i2 use stack-slot-for-p11'
All insns in this case will be valid in any pass. pre-reload will be
called in each pass. Insns after allocation will needn't in reloads.
It's my view at the problem.
Can you explain your ? I would understood.
Denis.