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