This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: new register allocator and HARD_REGNO_CALL_PART_CLOBBERED


Daniel Berlin wrote:
> No it wouldn't require new regclasses.
> It simply requires giving a HARD_REG_SET of preferred registers, rather
> than a register class.

Using HARD_REG_SETs as the result of regclass would solve this problem,
but one HARD_REG_SET would not be enough.  regclass currently gives you
up to two classes, a perferred and an alternate class.  For pseudos that
cross calls, each of these classes define two subsets, one for registers
in the respective class that require no caller saves, and one which requires
caller saves.  So the status quo is that you have four register sets;
replacing them with one seems rather restricting.
OTOH it is probably not necessary to have all four sets; if regclass also
considers the question of caller saves, it can factor them in as just another
cost, so two or three sets might do, with regclass having discretion if it
returns sets where some or all registers will require caller saves.
What you will need in order to make this work is regclass accessing data
flow information to determine during which calls each pseudo in question is
live.

> This is what the new register allocator converts the regclass into
> anyway.
> The whole notion of explicit register classes hardly ever meshes well
> with reality.

Yes, that's true.  It is an abstraction that enabled the old allocator to
handle the register sets more easily, but it fails when you try to describe
more complicated relationships.

> What we really need is for each port to have a function, that when
> passed a struct df (or something) with dataflow info already generated,
> gives us two arrays.  First, for each pseudo, a valid list of preferred
> usable registers (in terms of constraints like call clobbered or not,
> not in terms of non-conflicting with any other pseudo's set of
> registers)for that pseudo.  Second, a valid list of *all* usable
> registers for the pseudo.

Do you mean really *all* usable registers, or all registers that are still
cheaper than memory?
A register is usable if it can hold the mode, even if it needs reloads for
every single instruction that uses the pseudo.  This can even be beneficial
if the reloads are cheaper than reloads from memory, but if they are as
expensive or more expensive than loads from memory, than using that register
is likely a loss.  (the exception being if you couldn't use the register for
anything else during the lifespan of the pseudo, and the use of the register
doesn't introduce the need to save it, and the reloads not costing more than
memory accesses - than you might save a stack slot).

> This is basically what web_class ends up doing.
> We really shouldn't be trying to shoehorn pseudos into a fixed set of
> register classes for no good reason.

Agreed.  The issue is how and when the extra distinctions should be made.
The old register allocator considers call-clobberedness on the fly, thus
there is no need to store the register sets.  I wonder if storing multiple
HARD_REG_SETs for each pseudo/web will have a noticable impact on
memory usage / performance.
> 
> > So it seems that choose_spill_colors should take
> > HARD_REGNO_CALL_PART_CLOBBERED
> > into account, except that we are short of a mode there.
> No, this is also wrong.
> Note that choose_spill_colors uses the usable_regs. Usable_regs should
> *not* have any unusable regs in it.

But registers for which HARD_REGNO_CALL_PART_CLOBBERED for the required
mode are not completely unusable.  They require caller saves.
You already handle registers that are in call_used_reg_set in
choose_spill_colors, albeit I must say that adding a constant cost of
1000 to all registers that would require one or more caller-saves is
not a very fine-honed heuristic.

Is the current handling of caller-saves in choose_spill_colors something
you intend to move away int df.c?

> The only reason we have to test HARD_REGNO_MODE_OK *now* is because
> some ports (or regclass itself) are broken, so we end up with unusable
> regs in usable_regs (since it's initialized based on register class).

I don't see any connection of this test with the question if the register
will need caller saves.
	
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]