This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] RFC: Making control flow more explicit
- From: law at redhat dot com
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Michael Matz <matz at suse dot de>, Andrew MacLeod <amacleod at redhat dot com>, Steven Bosscher <s dot bosscher at student dot tudelft dot nl>, Daniel Berlin <dberlin at dberlin dot org>, Diego Novillo <dnovillo at redhat dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Tue, 12 Aug 2003 11:38:43 -0600
- Subject: Re: [tree-ssa] RFC: Making control flow more explicit
- Reply-to: law at redhat dot com
In message <20030812172208.GB31496@atrey.karlin.mff.cuni.cz>, Zdenek Dvorak wri
tes:
>Hello,
>
>> >> >because parent obviously is not what you want here. IIRC in the ssa d
>ce
>> >> >algorithm marking of the neccesary control statements is somehow
>> >> >done using dominator information.
>> >> The RTL version does use dominator information, the tree version does n
>ot
>> >> use dominator information to find necessary control statements.
>> >>
>> >> The tree version uses the nested control structure and goto following t
>o
>> >> deduce control dependency.
>> >
>> >The question is, do we eventually somewhen will need postdoms anyway?
>> Very very rarely within the DCE optimizer.
>
>if I understand the code correctly, only when some control statement is
>actually removed. This together with your claim that it occurs rarely
>implies that the optimization is almost useless in practice. Would not
>it then make sense to perform it only with -O3, then the extra time
>for computing postdominators would be more acceptable?
In my experience DCE rarely finds cases where IF/ELSE constructs can be
removed -- the vast majority of its benefit is in removing simple
assignment statements which have no visible effect on the execution of
the program. This is compounded by the fact that we linearize obviously
dead IF/ELSE constructs during CFG cleanups.
In fact, this is precisely why I have recommended using a simpler DCE
algorithm for wiping dead code between other SSA optimization passes
and using the more expensive algorithm once and only once just before
leaving SSA form. The idea being that the simple, fast DCE pass should
be suitable for running multiple times whenever we want to clear out dead
code from the stmt chains and we run the more complex version once per
function to catch things the simple/faster version misses.
I would hesitate to relegate removal of dead IF/ELSE constructs to -O3 since
removal of an IF/ELSE construct has the potential for improving things in
several significant ways.
Jeff