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: Mostafa Hagog <MUSTAFA at il dot ibm dot com>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Daniel Berlin <dberlin at dberlin dot org>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 9 Jun 2004 13:39:56 +0300
- Subject: Re: [patch] Lno branch merge part 1 -- df.c improvements
Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> wrote on 09/06/2004
05:23:59:
> 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).
Yes that is correct. However currently SMS calls df-analysis only once for
the whole function, build DDGs for all the single-basic-block loops saves
them
and then perform SMS on each one of them. Using the new improvements may
reduce memory usage. It this a trade-off between better memory usage and
having more accurate DF information?
Mostafa.