Re: [PATCH] operands_match_p for multiple hard registers

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

On Thu, 2005-02-24 at 15:40, David Edelsohn wrote:
> >>>>> Richard Earnshaw writes:
> 
> Richard> The more I think about it, the more I'm convinced the split is invalid. 
> 
> Richard> For starters it removes an insn that connects two operands in different
> Richard> modes.  That breaks the data flow graph between the setter and the user,
> Richard> so any post-reload pass could become confused (such as reg-renumbering).
> 
> 	If converting an instruction to NOTE_INSN_DELETED is invalid, then
> GCC has a few broken ports.  The idiom is used in Mips and IA-64 as well.
> 

Possibly.  Some of this isn't clearly defined, and what worked in the
past can suddenly end up causing problems :-)

> Richard> Secondly (although I'll admit I'm not familiar with the PPC
> Richard> architecture), I don't understand what it means to truncate a 128-bit
> Richard> TFmode value to a 64-bit DFmode value by doing nothing, especially if
> Richard> the former uses more physical registers than the latter.  If there
> Richard> really is a no-op truncation, then I think you need combine patterns in
> Richard> the MD file that describe the truncation-and-use operations.
> 
> 	The AIX/Darwin/PPC64 Linux long double is a pair of doubles.  The
> GCC semantics are:
> 
> "Each long double is made up of two IEEE doubles.  The value of the
> long double is the sum of the values of the two parts (except for
> -0.0).  The most significant part is required to be the value of the
> long double rounded to the nearest double, as specified by IEEE."
> 
> 	Truncating from TFmode to DFmode can be accomplished by narrowing
> the value to the most significant IEEE double.  The register number in the
> insn refers to the most significant register in the pair, so if the
> register allocator assigns the same register to the source and
> destination, the value can be truncated without a no-op FP move
> instruction. 

OK.  And the 'word' ordering of this is such that the 'Most-Significant
Double' (MSD) value is in the lower-numbered register -- a sort of
'little-endian'.  If the MSD were in the higher-numbered register, then
my guess is that this would just have worked as expected :-)

R.