This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Lno branch merge part 1 -- df.c improvements
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: gcc-patches at gcc dot gnu dot org, mustafa at il dot ibm dot com
- Date: Wed, 9 Jun 2004 04:23:59 +0200
- Subject: Re: [patch] Lno branch merge part 1 -- df.c improvements
- References: <20040608151354.GA4514@atrey.karlin.mff.cuni.cz> <F2326468-B962-11D8-8885-000A95DA505C@dberlin.org>
Hello,
> >this patch contains the following improvements to df.c:
> >
> >1) Avoid use of fibheaps (due to efficiency reasons) and remove
> > duplication of code between bitmap and sbitmap versions.
> >2) Makes it possible to run the analysis to just a part of
> > cfg (say body of a loop).
> >3) Makes handling of hard registers more efficient.
> >
> >The patch as whole was bootstrapped & regtested on i686. For ease
> >of reading I have split it to the parts corresponding to the
> >items described above (attached).
> >
> Didn't you have some numbers somewhere on how much faster this makes
> df.c?
on compilation of combine.c on i686 with -fnew-ra and -fweb (so that df.c
functions are used), I got the following times:
Without the patch:
dataflow : 0.29 ( 2%) usr 0.00 ( 0%) sys 0.67 ( 3%) wall
dataflow : 0.24 ( 2%) usr 0.00 ( 0%) sys 0.42 ( 2%) wall
dataflow : 0.25 ( 2%) usr 0.00 ( 0%) sys 0.37 ( 1%) wall
With the patch:
dataflow : 0.19 ( 2%) usr 0.00 ( 0%) sys 0.23 ( 1%) wall
dataflow : 0.16 ( 1%) usr 0.00 ( 0%) sys 0.16 ( 1%) wall
dataflow : 0.17 ( 1%) usr 0.00 ( 0%) sys 0.41 ( 2%) wall
Part 3) originally comes from rtlopt-branch, where it helped more significantly
on some testcases (that I unfortunately cannot find anymore).
Part two enables us to focus just on the parts of the cfg we are
interested in (the loops), which definitely seems good for performance.
This part might also be interesting in other parts of compiler (the
modulo scheduling, according to what was said in the talk on gcc summit,
might use it as well).
Zdenek