regrename speedup

Bernd Schmidt bernds_cb1@t-online.de
Thu Nov 12 18:32:00 GMT 2009


I wrote:

> The testcase (PR38582) still consumes a lot of time in the renamer,
> but the problem is shifted to merge_overlapping_regs which probably
> needs rewriting.

The following patch cures the problem entirely.  The initial scanning
phase of the renamer is rewritten to keep track of conflicts between
chains, as well as recording lifetimes of hard registers.  This removes
the need for merge_overlapping_regs to rescan the basic block every time.

For some cases involving multiword hard registers, I've made it give up,
since the effort of tracking the individual hard regs gets too hairy if
there is non-exact overlap.  This does not seem to happen often enough
to worry about, at least on x86.  On the plus side, the conflicts
information gathered by the new code is slightly less conservative, as
we no longer treat all outputs as earlyclobbers for the last insn in a
chain when determining conflicts.

I've bootstrapped and regression tested this patch on i686-linux with
another small patch to force flag_rename_registers to 1.

Ok (and for which stage)?


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rr-speed3.diff
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20091112/e33bc98f/attachment.ksh>


More information about the Gcc-patches mailing list