Re: [PATCH] operands_match_p for multiple hard registers

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Thu, 2005-02-24 at 01:36, David Edelsohn wrote:
> 	My recent change to trunctfdf2 for AIX/Darwin/PPC64 Linux long
> double format exposed a failure where GCC would match an alternative
> requiring matching constraints for a case where the two operands are
> different registers.  With help from Richard Earnshaw, I finally tracked
> this down to a piece of code in reload.c:operands_match_p() that considers
> the different operands a match on purpose.
> 
> 	The code specifically matches the *last* register of a multiple
> hard register group, as explained in the comment:
> 
>       /* On a WORDS_BIG_ENDIAN machine, point to the last register of a
>          multiple hard register group, so that for example (reg:DI 0) and
>          (reg:SI 1) will be considered the same register.  */
> 
> Due to the specific register allocation occuring for the example, the code
> adjusted the register numbers to cause a match.
> 
> 	This behavior only seems to make sense for scalar integers, so I
> am proposing restricting the behavior to that subset of modes.  I
> considered using CANNOT_CHANGE_MODE_CLASS, but I cannot see where the
> benefit would justify the more extensive changes necessary to invoke that
> optional macro.

I was mulling this problem over last night when I was trying to get to
sleep.

The more I think about it, the more I'm convinced the split is invalid. 

For starters it removes an insn that connects two operands in different
modes.  That breaks the data flow graph between the setter and the user,
so any post-reload pass could become confused (such as reg-renumbering).

Secondly (although I'll admit I'm not familiar with the PPC
architecture), I don't understand what it means to truncate a 128-bit
TFmode value to a 64-bit DFmode value by doing nothing, especially if
the former uses more physical registers than the latter.  If there
really is a no-op truncation, then I think you need combine patterns in
the MD file that describe the truncation-and-use operations.

R.