This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: new register allocator and HARD_REGNO_CALL_PART_CLOBBERED
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Joern Rennecke <joern dot rennecke at superh dot com>
- Cc: Herman ten Brugge <hermantenbrugge at home dot nl>,Dale Johannesen <dalej at apple dot com>,gcc at gcc dot gnu dot org
- Date: Tue, 13 May 2003 10:54:59 -0400
- Subject: Re: new register allocator and HARD_REGNO_CALL_PART_CLOBBERED
On Tuesday, May 13, 2003, at 06:27 AM, Joern Rennecke wrote:
Herman ten Brugge:
For example the c4x target will only save the integer part of
register r4.
So if we need an integer register we can use r4 during a call. If we
need
a floating point register we can not use r4 during a call.
Daniel Berlin:
Uggh.
That's horrific.
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.
Either would be better than hacking the new-ra to handle these
oddities, and the first would result in faster and better allocation.
If you really want me to give you a patch to fix this in new-ra, i
will, but i *really* don't think it's the right place.
regclass is not supposed to know about lifetimes, and you need to know
if and
how often the lifetimes of a pseudo cross a conflicting call, and what
the
register pressure on sufficiently call-saved registers are there to do
this
right. So it is the job of the register allocator.
Then regclass is worthless, to be honest.
It hands us register classes containing invalid registers for a pseudo.
We can't rely on it to give us a set of registers that are usable for
the register.
For the invalid registers it gives you, one doesn't know how much
better or worse any other set of registers is.
So remind me again why it's helpful?
I'll note that this is one of the reasons it's replaced with the
web_class stuff (in combination with pre-reload) on new-regalloc-branch.
It's not difficult, it's just exactly the kind of extra-special port
specific
stuff we don't want new-regalloc to be directly handling if it can
avoid it.
It's not all that special.
Actually, it is.
These are hard regs that can have either an integer or floating point
value in them (which isn't typical of our main platforms), but are only
partially clobbered if they contain integer values.
This is untypical of our main platforms, thus, "special".
It may be common in embedded platforms, it would not surprise me.
However, in order for the new-register allocator to make a good
decision here, it needs to know what registers would be usable ahead of
actual allocation time (as opposed to just throwing out regs it thought
it could use when it comes time to get a free register), so it can
accurately estimate costs, and model conflicts. In turn, this affects
coalescing and actual allocation.
The actual allocator is *not* the right place to do this pruning,
although it may go into one of the ra*.c files, which consist of more
than just the actual allocator i was referring to.
Herman wanted to do this in get_free_reg, which, for the reasons i just
pointed out, is exactly *not* where it belongs.
The SH5 has it too,
Embedded platforms are the most prolific producers of weird register
constraints.
--Dan