Re: [PATCH] Fix PR target/33923

[Jim Wilson <wilson at specifix dot com>]

On Wed, 2007-11-14 at 23:35 +0100, Eric Botcazou wrote:
> OK.  But it is known that it is not necessary only for this case, see for 
> example the x86 port with MMX and SSE registers.

That looks like another instance of the MODES_TIEABLE_P issue to me.
The x86 port allows QImode/HImode to tie to SImode, but MMX/SSE regs
don't allow QImode/HImode accesses, so we need CANNOT_CHANGE_MODE_CLASS
to prevent them.

> I'd dispute that.  MODES_TIEABLE_P is only used for local register allocation; 
> in particular, it is totally ignored by the class selection code.  The latter 
> only knows about HARD_REGNO_MODE_OK and CANNOT_CHANGE_MODE_CLASS; now, since
> HARD_REGNO_MODE_OK is not sufficient as the example shows, I think that the 
> CANNOT_CHANGE_MODE_CLASS change is needed independently of MODES_TIEABLE_P.

But there is no problem here without the mode tying that the local
register allocator did.  The class selection code knows that only DImode
is allowed in a br reg because HARD_REGNO_MODE_OK says so.  The register
allocator knows the same thing.  It is only because the local register
allocator tied a DImode pseudo to a SImode pseudo that we have a
problem.  The register allocator only checks if the first pseudo-reg
fits in the chosen hard register.  It assumes the other pseudo registers
tied to the first don't have to be checked because MODES_TIEABLE_P said
they are OK, unless CANNOT_CHANGE_MODE_CLASS indicates to the contrary.

Thus the problem can be fixed with either the MODES_TIEABLE_P or
CANNOT_CHANGE_MODE_CLASS change, with the CANNOT_CHANGE_MODE_CLASS
change being preferable in this case.

Perhaps there is a difference of perspective here.  MODES_TIEABLE_P
predates CANNOT_CHANGE_MODE_CLASS by many years.  The original intent
was to prevent this stuff with MODES_TIEABLE_P.
CANNOT_CHANGE_MODE_CLASS was added later for a different reason, i.e.
the FP reg int/fp value representation problem that prevents use of
subregs.  CANNOT_CHANGE_MODE_CLASS has proved to be rather useful, and
its use has been expanded to many other places in the compiler and its
meaning has been generalized.  But from my perspective, it is still
MODES_TIEABLE_P first and CANNOT_CHANGE_MODE_CLASS second.  At least
until someone obsoletes MODES_TIEABLE_P by rewriting the register
allocator.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com