Re: postreload-gcse heuristics broken?

[Mostafa Hagog <MUSTAFA at il dot ibm dot com>]

Ulrich Weigand/Germany/IBM@IBMDE wrote on 23/01/2005 17:34:14:

> Ayal Zaks wrote:

> > >resulting in much worse code than before in some cases.
> >
> > Is it easy to see what causes the degradation in these cases?

> Well, I noticed the issue on mgrid's resid function, which is
> a triply-nested loop; what postreload-gcse does to this loop
> is to split each of the loop backedges and insert tiny basic
> blocks consisting only of a load instruction.

> So the hot path goes instead of through a single branch now through
> a sequence of two taken branches nearly immediately following
> each other; this doesn't do the pipeline any good ...

> Also, it would appear to me that postreload-gcse inserts much
> more moves that it is able to eliminate:

> generating move from 7 to 4 on edge from 6 to 2
> generating move from 2 to 4 on edge from 1 to 2
> generating move from 10 to 10 on edge from 1 to 2
> generating on edge from 6 to 2 a copy of load: (set (reg:DI 10 %r10)
> (mem:DI (plus:DI (reg/f:DI 15 %r15)
> (const_int 296 [0x128])) [31 pretmp.29+0 S8 A8]))
> generating move from 1 to 1 on edge from 1 to 2
> generating on edge from 6 to 2 a copy of load: (set (reg:DI 1 %r1)
> (mem:DI (plus:DI (reg/f:DI 15 %r15)
> (const_int 304 [0x130])) [32 prephitmp.26+0 S8 A8]))
> generating move from 4 to 4 on edge from 5 to 3
> generating move from 3 to 4 on edge from 2 to 3
> generating move from 5 to 5 on edge from 2 to 3
> generating on edge from 5 to 3 a copy of load: (set (reg:DI 5 %r5)
> (mem:DI (plus:DI (reg/f:DI 15 %r15)
> (const_int 264 [0x108])) [27 pretmp.45+0 S8 A8]))
> generating move from 5 to 7 on edge from 3 to 4
> generating on edge from 4 to 4 a copy of load: (set (reg:SI 7 %r7)
> (mem:SI (plus:DI (reg/f:DI 15 %r15)
> (const_int 168 [0xa8])) [15 ivtmp.115+0 S4 A8]))
> Edge 4->4 redirected to 8
> Edge 5->3 redirected to 9
> Edge 6->2 redirected to 10
> deleting insn:
> (insn/v 376 374 62 2 (set (reg:DI 1 %r1)
> (mem:DI (plus:DI (reg/f:DI 15 %r15)
> (const_int 304 [0x130])) [32 prephitmp.26+0 S8 A8])) 42 {*movdi_64} (nil)
> (nil))

> GCSE AFTER RELOAD stats:
> copies inserted: 4
> moves inserted:  8
> insns deleted:   1

The main goal from gcse is to reduce the number of instructions executed
dynamically.  For example it would delete an instruction from inside a
loop and put 2 or more instruction on several blocks that leads to it.
It means 2 or more new instructions but less instructions executed.

The main problem here is that the counts that postreload gcse is using
to make a decision are wrong.  There are two possible ways to fix this:
1. Disable postreload-gcse when profile information is not available.
2. Use the branch probabilities estimation instead of edge counts - this
   information will be available in both cases (w/o profiling).  And when
   the profile information is available it will be up-to-date.

Mostafa.

> Bye,
> Ulrich

> --
> Dr. Ulrich Weigand
> Linux on zSeries Development
> Ulrich.Weigand@de.ibm.com