This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] third liveness pass
- From: Jan Hubicka <jh at suse dot cz>
- To: Richard Henderson <rth at redhat dot com>, Jan Hubicka <jh at suse dot cz>,gcc at gcc dot gnu dot org, law at cygnus dot com, gcc-pdo at atrey dot karlin dot mff dot cuni dot cz
- Date: Mon, 27 May 2002 08:44:38 +0200
- Subject: Re: [RFC] third liveness pass
- References: <20020526122147.GM21915@atrey.karlin.mff.cuni.cz> <20020526163817.A1939@redhat.com>
> On Sun, May 26, 2002 at 02:21:47PM +0200, Jan Hubicka wrote:
> > But interestingly the only C++ benchamrk, eon shows different figures.
> > The savings are about 2.2% in code size and 1.6% performance (*).
> Interesting. I wonder if someone with an interest in C++ can
> corroborate with "real" applications.
Yes, thats why I am asking here :)
> > Similary I think the liveness costs can be made much lower, since
> > currently we don't compute bitmaps of local properties, instead re-scan
> > every time that can be expensive especially when dead store removal has
> > been added.
> How can we, when the local property is dependent on which
> insns are deleted as dead code?
Yes, this is problem of course.
One can jump into assumption that the dead code removal is rare and
first do the relaxation without thinking about removal and then check if
something is dead.
Other sollution would be to use DU/UD that don't need to rerun
> > Perhaps the dead code removal is better done using DU/UD chains and
> > curent ssa-dce code converted to these, but I am not sure how popular
> > step this can be.
> I wouldn't have a prolem with that at all, if it is faster.
> You'd have to rewrite the autoinc portions of life_analysis
> at the same time, but it should be fairly straight-forward
> to re-implement the existing algorithms with DU/UD chains.
Yes, I have to check how fast/slow DU/UD is. It is not incredibly cheap
information as it can get large (even counting memory overhead) for
artifical testcases, so I am not sure whether it is way to hell or not.
But many compilers do DU/UD and in case we give up SSA on lowlevel RTL,
I guess this is the second sensible transfofmatiom.
Once DU/UD is build the dead code removal can be followed by other
On the cfg branch I run DU/UD for webizing and by quick checking on
combine, the three liveness passes accounts 9% of compilation, while two
webizers 3%, so it is somewhat faster...