This is the mail archive of the
mailing list for the GCC project.
Re: HARD_REGNO_MODE_OK vs the register allocator
- From: Michael Matz <matz at suse dot de>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Geoff Keating <geoffk at geoffk dot org>, <dj at redhat dot com>,<gcc-patches at gcc dot gnu dot org>
- Date: Fri, 2 May 2003 14:31:50 +0200 (CEST)
- Subject: Re: HARD_REGNO_MODE_OK vs the register allocator
On Wed, 30 Apr 2003, Richard Henderson wrote:
> [ Subject line changed in hopes of piquing new-ra folk's interest. ]
> Lemme get this straight: You *could* have an SImode value in $r7/$r8
> if the constraint were GENERAL_REGS, but not if it were EIGHT_REGS?
Which indeed seems to be an ugly "feature" of stormy16 ;-)
> handling this. It's kind of an edge condition though -- we've said
> elsewhere that it's wrong for HARD_REGNO_MODE_OK to return true for
> a double-word value in the last register of the physical reg set.
> We should make up our mind. Either it's the allocator's job to test
> that there are indeed HARD_REGNO_NREGS remaining in the chosen class,
> or HARD_REGNO_MODE_OK should instead also take the class it's supposed
> to be testing against.
> Personally I prefer the former.
Me too. HARD_REGNO_MODE_OK should be left depending just on the mode and
the regno. And the allocator should ensure that the allowed class isn't
left by multi-word regs. Since the begin I undestood the regclass
constraints on instructions as limiting the set of overall available
hardregs, while HARD_REGNO_MODE_OK is used to further limit the set of
possible _begin_ colors (to every second for instance).