This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Problem in reload


I'm having a problem with reload on rs6000 (Darwin, but I think this can
affect other OS's) with the following insn:

(insn 559 553 550 (set (mem:CCUNS (plus:SI (plus:SI (reg/f:SI 1 r1)
                     (const_int 65536 [0x10000]))
                 (const_int 18040 [0x4678])) [0 S4 A32])
         (compare:CCUNS (reg:SI 4 r4 [306])
             (const_int 255 [0xff]))) 430 {*cmpsi_internal2} (insn_list 548 
(nil))
     (nil))

On this machine, the result of the compare is a CR register.  You cannot
move these directly to memory; you have to go through a general reg.
Furthermore the (PLUS (R1) (65536)) has to go into a register; as it
happens, this is inherited from a previous reload, and is known to be in 
R7.
A replacement[] pointing to this PLUS is duly created.  So after
emit_reload_insns() the code looks like this:

(insn 559 553 10777 (set (mem:CCUNS (plus:SI (plus:SI (reg/f:SI 1 r1)
                     (const_int 65536 [0x10000]))
                 (const_int 18040 [0x4678])) [0 S4 A32])
         (compare:CCUNS (reg:SI 4 r4 [306])
             (const_int 255 [0xff]))) 430 {*cmpsi_internal2} (insn_list 548 
(nil))
     (nil))

(insn 10777 559 10778 (set (reg:CC 8 r8)
         (reg:CC 68 cr0)) -1 (nil)
     (nil))

(insn 10778 10777 550 (set (mem:CC (plus:SI (plus:SI (reg/f:SI 1 r1)
                     (const_int 65536 [0x10000]))
                 (const_int 18040 [0x4678])) [0 S4 A32])
         (reg:CC 8 r8)) -1 (nil)
     (nil))

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]