This is the mail archive of the gcc@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]

Re: postreload-gcse heuristics broken?





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

"insns deleted" is wrong, this is due to a bug in the dumps of
postreload-gcse. We have two places in which we delete instructions and
only one of them is reported.

I have prepared a patch to prevent postreload-gcse to split critical
edges (as Ayal suggested to me) - this should do the trick for you.
The patch also includes the fix for the dumps bug.

postreload-gcse didn't cause any degradation in G5 so I cannot test
if the patch fixes your problem.  can you test it?

Mostafa.


(See attached file: postreload_gcse_nopdf.patch)

Attachment: postreload_gcse_nopdf.patch
Description: Binary data


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