This is the mail archive of the 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: 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.  ]

worked ;)

> 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).


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