Re: [new-regalloc-branch]: pre-reload pass

[Denis Chertykov <denisc at overta dot ru>]

Michael Matz <matz@kde.org> writes:

> Hi again,
> 
> I only wanted to add some thoughts how I think pre-reload should work
> (besides what I already said last time):  Basically I want to collect as
> much information as possible by the little work as possible.  The
> allocator basically works on register references, right now through what
> df.* makes of them (the df_ref's).  I want a similar thing but with regard
> to the allocator.  Basically a regref should contain these things:
> struct ra_ref {
>   rtx ref;  /* the regref itself */
>   rtx *loc; /* a location in insn with ref==*loc.  */
>   rtx insn; /* the containing insn.  */
>   int opnum;  /* The containing operand number of this regref.  */
>   int type; /* USE or DEF or USE in adress? others? */

                CLOBBER

>   char *constraint;  /* if this reg is the whole operand, the constraints
>                         for the chosen alternative.  */

Why you want to have this ?
If you want to have an additional information for debugging may be
better to have the operand alternative number. 

>   HARD_REG_SET hardregs;  /* the possible hardregs.  */
>   ra_ref *matches;
>   ra_ref *matched_by;
>   ra_ref *uplink;  /* for the allocator to form webs.  */
>   ... other info from struct web_part ...
>   ... and maybe other interesting things I right now don't remember ...
> }


> 
> and various linked lists containing such ra_refs (per insn, per regno,
> may be per insn/opnum, and so on).  The above fields are not valid at all
> times.  Basically pre-reload should scan all insns, first setting up the
> initial lists of those refs, with the information it can, and at the same
> time scan for probably invalid regs.  For each insn it detects the best
> alternative, and according to that maybe emits some insns, and changes
> the invalid insn, and _also_ updates the above lists of ra_refs (e.g. add
> information about what alternative was chosen, i.e. adds the constraints
> and fills the hardregs member).
> 
> After scanning all insns, it repeats everything if there were some
> changes.  After this the ra_refs should contain precise information about
> which hardregs are allowed for each pseudo in each insn, and the allocator
> can do it's work.  If it's able to satisfy all those externally noted
> constraints in the ra_refs, there should be no invalid insns left.  What
> can happen in that process is when forming the webs the resulting hardregs
> gets empty (all hardregsets for all refs in a web must be intersected).
> In that case this indicates some insns with conflicting constraints.
> There are multiple solutions possible, I'm not yet sure of which is
> best.

For example one my think:

I think two web parts for one register can't be connected to one web
if his hardregs (from ra_ref) are not equal (Or even are not
GENERAL_REGS). We must record such situation and emit move insns if
allocator can't coalesce it. 
IE
three insns:

(set (reg 101) (symbol_ref "user_var"))       ;; reg 101 must be GENERAL_REGS
... many other insns without reg 101
(set (reg 100) (mem (reg 101)))               ;; reg 101 must be BASE_REGS
... many other insns without reg 101
(set (reg 101) (plus (reg 101) (const_int 4)));; reg 101 must be IMM_REGS

We must represent insns as:

(set (reg 101) (symbol_ref "user_var")) ;; reg 101 must be GENERAL_REGS
... many other insns without reg 101
(set (reg 101) (reg 101))               ;; Special insn (web barrier)
(set (reg 100) (mem (reg 101)))         ;; reg 101 must be BASE_REGS
(set (reg 101) (reg 101))                      ;; Special insn (web barrier)
... many other insns without reg 101
(set (reg 101) (plus (reg 101) (const_int 4))) ;; reg 101 must be IMM_REGS


In general we can have "web barriers" after/before each insn
which requires register to be not in GENERAL_REGS.
(IMHO: it will be an ideal spilling to wider class, not to memory.)
May be too many work for coalesce.


> 
> I only wanted to notify you of these plans, so that when working on
> pre-reload or other stuff (also webclass is connected to this) you can
> keep this in mind, which probably makes further work more easy.  I don't
> expect you are doing the above work, but at least don't make it harder
> than necessary ;)

I will not continue my work on web_class at all. Because it will not
needed.
Also, I want to start work on collecting info to ra_ref's.
(IMHO: it's a good solution.)
May be we can divide tasks.

Denis.