Regression in code quality with PA 8000 scheduling

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

In testing fixes for the problem with 950704-1.c, I noticed that the
code generated at -O2 (and -O3) was worse than before (ie., 3.0.3 and
3.1).  The problem appears to be a subtle interaction between scheduling
and global register allocation.

With the previous scheduling, these two insns were ordered as follows:

(insn 55 196 61 (set (reg:SI 102)
        (ior:SI (ge:SI (subreg:SI (reg/v:DI 97) 0)
                (const_int 0 [0x0]))
            (lt:SI (subreg:SI (reg/v:DI 96) 0)
                (const_int 0 [0x0])))) 4 {iorscc} (nil)
    (expr_list:REG_DEAD (reg/v:DI 96)
        (nil)))

(insn 61 55 56 (set (reg:DI 94)
        (reg/v:DI 97)) 118 {*pa.md:3087} (nil)
    (expr_list:REG_DEAD (reg/v:DI 97)
        (nil)))

With the 8000 scheduling, the order of these two insns is reversed.

The first order results in the following preferences and conflicts:

;; 94 preferences: 20 28
;; 97 conflicts: 95 96 97 99 102 104 105 1 19 20 21 30
;; 97 preferences: 28

The 8000 scheduling results in:

;; 94 preferences: 28
;; 97 conflicts: 94 95 96 97 99 104 1 20 21 30

The result is DI 97 does get allocated to register 28.  This can snowball
to cause a stack frame to be introduced, etc.

I'm not sure what the best fix is.  It would seem the conflict is not
real and 28 should be a preference for 97.  I was wondering in looking
at this if there needs to be a copy_prop_backwards for argument and
return registers.

There appeared to be a similar problem allocating registers in the code
generated for the perl module gv.c.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)