Since the arguments are gimple registers, gimple optimizers are happy to create many
references to it.
While lowering them to RTL these however compile to memory loads causing number of
redundant loads.
The attached quicksort loop on when compiled with -O2 -fno-loop-optimize (the other
being needed only for clarity of the testcase) produces such a funny sequence:
movl 8(%ebp), %eax # 143 *movsi_1/1 [length = 3]
movl 8(%ebp), %edx # 171 *movsi_1/1 [length = 3]
movl 8(%ebp), %ebx # 145 *movsi_1/1 [length = 3]
These are comming from:
median = data[start];
pos.22 = start + 1;
if (end - start <= 1) goto <L6>; else goto <L25>;
where each of these compiles into RTL expression that looks different to CSE:
(insn 16 15 18 1 (set (reg/v:SI 66 [ median ])
(mem/s:SI (plus:SI (mult:SI (reg/v:SI 68 [ start ])
(const_int 4 [0x4]))
(reg/f:SI 70)) [3 data S4 A32])) -1 (nil)
(nil))
(insn 18 16 20 1 (parallel [
(set (reg/v:SI 60 [ pos.22 ])
(plus:SI (reg/v:SI 68 [ start ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
(insn 20 18 21 1 (parallel [
(set (reg:SI 71)
(minus:SI (reg/v:SI 69 [ end ])
(reg/v:SI 68 [ start ])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
(insn 21 20 22 1 (set (reg:CCGC 17 flags)
(compare:CCGC (reg:SI 71)
(const_int 1 [0x1]))) -1 (nil)
(nil))
Similarly we get redudnant loads inside the loop itself.
Not sure about sollution - making arguments nongimple registers does not lead
optimizers to deal with them very nicely, forcing
expander to load memory operands to register in prologue would lead to unnecesarly
long lifetimes...
forcing memory operands to registers in RTL generation is something we want to avoid ;)
Ideas?
--
Summary: arguments being gimple registers cause redundant memory
loads
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hubicka at gcc dot gnu dot org
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org,rth at redhat dot com,stevenb at suse dot de
GCC target triplet: i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18137
