64-bit PowerPC code quality regression

[David Edelsohn <dje at watson dot ibm dot com>]

	On the trunk, GCC now is producing poor code for some constants
when targeting 64-bit PowerPC and the bad choice for generating the
constant is being introducted during sched1.  For 32-bit targets, the code
is fine.

For instance,

long
ret ()
{
    return -65536L;
}

produces the following for 32-bit PowerPC:

        lis 3,0xffff

For 64-bit PowerPC (AIX), it produces:

        li 3,-1
        rldicr 3,3,0,47

(clear lower bits of -1) when "lis" still is valid (lis sign-extends the
constant).  This two instruction sequence is produced by a splitter, but
the matcher itself satisfies this constraint and should generate "lis".

	The change occurs between regmove and sched1.  In 18.regmove dump
file the instruction sequence looks like:

(insn 18 22 21 (set (reg/i:DI 3 r3)
        (const_int -65536 [0xffffffffffff0000])) 301 {*movdi_internal64} (nil)
    (expr_list:REG_EQUAL (const_int -65536 [0xffffffffffff0000])
        (nil)))

However, in 19.sched dump file the instruction has been converted to:

(insn 26 22 27 (set (reg/i:DI 3 r3)
        (const_int -1 [0xffffffffffffffff])) 301 {*movdi_internal64} (nil)
    (nil))

(insn 27 26 21 (set (reg/i:DI 3 r3)
        (and:DI (rotate:DI (reg/i:DI 3 r3)
                (const_int 0 [0x0]))
            (const_int -65536 [0xffffffffffff0000]))) 244 {*rotldi3_internal4} (insn_list 26 (nil))
    (nil))

	I am having a hard time figuring out where sched is making this
change and why and how to prevent it.  The machine description seems
correct.  Why has the splitter been applied unnecessarily?

	I suspect that this is some sort of 32x64 problem exposed by the
trunk's use of "long long" for CONST_INT on 64-bit targets.  Any helpful
advice would be appreciated.

Thanks, David