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:
> 
> On Tue, 13 May 2003, Joern Rennecke wrote:
> 
> > Daniel Berlin wrote:
> No, they are invalid. It frequently gives us regs we can't use *at all*
> (IE regardless of call status, they just aren't even okay for the
> mode at all).

That is a different problem then, which indeed would be a bug in regclass.

> > You can do this ahead of time, by looking at the modes of the pseudos
> > you want to allocate in the register.
> 
> Which is what i suggested, rather than putting it in get_free_reg.
> The portion of code we have now that looks at the modes is regclass.
> So i suggested it goes there.

That would require to create new register classes to cover all
call-used/call-saved boundaries, both for full and partial saves, plus the
resultant unions and intersections.  And creating a lot of new register
classes willy-nilly tends to have adverse effects on register allocation,
at least with the old register allocator.  And you'd have to have non-trivial definition of CLASS_LIKELY_SPILLED_P to avoid false positives.  So that would
require a split of the machine descriptions, have one for the old, and one for
the new register allocator - I doubt that we want that.
What is worse, some optimizers - e.g. in regmove - check if the preferred
class is the same to see if they can reasonably tie a register.  We'd have
to have a new target macro to tell if regclasses are similar enough for
the purposes of such optimizations.

The problem is that regclass just finds one or two classes that are
supposed to be suitable to hold the pseudo and have lower overall cost
than a stack location for doing the individual accesses, without regards
to register pressure or lifeness constraints.
The user of this information is supposed to distinguish between call-saved
and call-used registers in the returned classes, and to prefer the former
for values that cross calls, and hence prefer the latter for values that
don't cross calls.  The latter goal is traditionally accomplished by
using REG_ALLOC_ORDER so that for each set of otherwise equivalent
registers, call-clobbered registers precede partly call-clobbered registers,
which in turn precede call-saved registers.
The only twist is that HARD_REGNO_CALL_PART_CLOBBERED brings in here is
that which registers are (partly) clobbered by calls depends on the mode 
of the value.

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.
OTOH the cost of doing caller-saves optimally (we don't do that yet, but
really we should...) depends on the mode(s) you need to be saved, so it
seems advisable to have a list of modes for each web that are call crossed,
plus a count of how many calls are crossed in each mode.  By keeping these
lists sorted by mode, they can be easily merged when webs are merged.

> I didn't claim it should be in reload, that's clearly the wrong place too.

I must have misunderstood you.  What exactly did you think should reload
fix up in this paragraph:
> You aren't going to be able to get this to happen in a reasonable way.
> Ideally, the regclass pass should be handing us a register class that's 
> actually valid here. It's not.  Reload should also be fixing the 
> new-ra's mistake (which isn't really it's fault).  It doesn't.

Going back a bit in this thread, I see:
Herman ten Brugge:
> I do not think the problem is in df.c. The code in df.c walks through the
> rtl and sets clobbered/used register info. We do not yet know what mode
> the hard registers will get (reg_raw_mode can not be used here). The mode
> is assigned in the new-ra pass.

I must say that I don't understand why reg_raw_mode can not be used there.
reg_raw_mode should be HFmode for the c4x registers in question, and
Dale Johannesen's patch to df_insn_refs_record should find the calls/register
combinations that could potentially cause a problem.

Looking at df.c, I get the impression that df.c tries to collect
information that is simply not available in general.  It still uses
the CLASS_CANNOT_CHANGE_MODE_P macro, which has been superceded by
CANNOT_CHANGE_MODE_CLASS / REG_CANNOT_CHANGE_MODE_P, and I can't see how
you can properly update the code without collecting mode information and
using it in ra-rebuild.c .  Disabling all mode changes for a class because
any change doesn't work is prohibitive; not disabling any mode changes
misses the point that sometimes you have to inhibit mode changes because
the register numbering might disagree with the endianness of the processor.

-- 
--------------------------
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]