RFC: bug in code hoisting

Dale Johannesen dalej@apple.com
Fri Mar 11 02:16:00 GMT 2005


[On PPC, R3 is the first parameter register]
In the first block of a function, the code comes in looking like this:

(insn 3 2 4 0 (set (reg/f:SI 126 [ this ])  (reg:SI 3 r3 [ this ])) -1
....
(insn 15 14 16 1 (set (reg:SI 3 r3)  (reg/f:SI 126 [ this ])) -1 (nil)

(call_insn 16 15 89 1 (parallel [
             (set (reg:SI 3 r3)
                 (call (mem:SI (symbol_ref:SI 
("&L__ZNK7QWidget7getViewEv$stub") <
             (use (const_int 0 [0x0]))
             (clobber (scratch:SI))
         ]) -1 (nil)
     (expr_list:REG_EH_REGION (const_int 3 [0x3])
         (nil))
     (expr_list:REG_DEP_TRUE (use (reg:SI 3 r3))
         (nil)))

CSE eliminates the redundant move:

(insn 3 6 4 0 (set (reg/f:SI 126 [ this ]) (reg:SI 3 r3 [ this ]))
....
(call_insn 16 14 89 0 kwq/KWQSlider.mm:198 (parallel [
             (set (reg:SI 3 r3)
                 (call (mem:SI (symbol_ref:SI 
("&L__ZNK7QWidget7getViewEv$stub") <
             (use (const_int 0 [0x0]))
             (clobber (scratch:SI))
         ]) 369 {*call_value_nonlocal_sysv} (nil)
     (expr_list:REG_EH_REGION (const_int 3 [0x3])
         (nil))
     (expr_list:REG_DEP_TRUE (use (reg:SI 3 r3 [ this ]))
         (nil)))

Now GCSE discovers a computation of R126+constant in a lower block that 
it wants
to hoist into this block.   Since the block is terminated by a throwing 
call, the hoisting
code tries to put it before all the parameter loads for the call, which 
is done by
find_first_parameter_load.  In this case, there is no such load, so 
find_first_parameter_load
continues to the beginning of the function, and that's where the code 
is hoisted to:

(insn 117 6 114 0 (set (reg/f:SI 141) (plus:SI (reg/f:SI 126 [ this ]) 
(const_int 72 [0x48]))

(insn 3 114 4 0 (set (reg/f:SI 126 [ this ]) (reg:SI 3 r3 [ this ]))
....

Which is wrong.

I'm thinking a change to find_first_parameter_load is in order, to make 
it do what its
name and the preceding comment suggest it should do, like this 
(untested):
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs1.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20050311/eea6abd9/attachment.txt>
-------------- next part --------------

But this is old and stable code, and I'm disturbed this hasn't shown up 
before.
It only happens with -Os, but we use that a lot here, and it looks like 
PRE ought
to have the same bug.  Comments?


More information about the Gcc-patches mailing list