Re: Regression in code quality with PA 8000 scheduling

[law at redhat dot com]

In message <200205112146.g4BLksVY025675@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > 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.
Can you send me the full .lreg dump?  There's simply not enough information
in this message for me to start to look at this problem.
jeff