Re: New test for g77 regression

[Dale Johannesen <dalej at apple dot com>]

On Friday, March 8, 2002, at 01:23 PM, David Edelsohn wrote:

>>>>>> Dale Johannesen writes:
>
> | The problem is that gen_move_insn() cloned the MEM when creating 10778,
> | and did not create an extra replacement[] for the cloned inner PLUS.
> | This happens because there is no move pattern for CCUNS on rs6000, only
> | for CC.  gen_move_insn does call copy_replacements on the MEM, but this
> | does not go down far enough to find the inner PLUS.
>
> | Obviously adding a pattern to move CCUNS in rs6000.md will fix this, and
> | that is probably safest, but it will result in some duplicated code
> | (there are 4 possible CC modes).  I wonder if it is appropriate to do
> | something in reload.  It seems as though perhaps copy_replacements ought
> | to go down farther, but there is a comment indicating the behavior is
> | intentional, although it doesn't explain why.  Any advice?
>
> 	This appears to be both an overlooked case in reload and also a
> potential bug in the PowerPC port.  If an MD creates a port-specific MODE,
> it should provide a pattern describing how to move that mode.
>
> 	There isn't any pattern alias mechanism to tell GCC to use movcc
> for those other modes.  Could we remove the "CC" modes from the movcc
> patterns and have the predicate restrict the operands to one of the four
> CC modes?  Otherwise, I do not see any choice but to duplicate the
> patterns for the four modes.

I've been using the duplicated-code version locally for some time without
problems.  (There should be some submissions coming up RSN.  I'm unsure
about whether I should submit this one; advice?)  The modeless
version is shorter and seems cleaner to me, but you do get this warning
about "operand X missing mode", which suggests somebody doesn't think
it's a good idea.

> 	While we should be able to fix this in reload,

Richard Henderson has submitted such a patch; unfortunately I've been 
dealing
with a meltdown here and have been unable to try it.

> should rs6000.md
> also be fixed?  I do not have any good instincts about the way that these
> modes are used and how that interacts with the rest of GCC.

Neither do I.