This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Dead Store Elimination
- From: law at redhat dot com
- To: Steven Bosscher <stevenb at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 16 Feb 2004 07:51:49 -0700
- Subject: Re: [tree-ssa] Dead Store Elimination
- Reply-to: law at redhat dot com
In message <firstname.lastname@example.org>, Steven Bosscher writes:
>> This adds dead store elimination to our list of supported optimizations.
>Cool! Only, since you've put it after the final DCE pass, do we
>kill the statements feeding the dead stores?
Actually, we run it twice. The first pass actually catches the
vast majority of the dead stores (and right now there aren't a
terribly whole lot of them anyway). Thus the code which feeds
the dead store will be removed by the cddce pass.
>I was wondering, would it be possible to fold this pass into our
>aggressive dead code elimination pass? Both DSE and DCE require
>post-dominance info, and DCE can do better if it works in
>parallel with DSE.
It's possible in the sense that they could share building of the
PDOM information. What needs to happen for that is we simply need
to mark PDOMs as a property needed by both passes and preserved by
>I was thinking that in cd-DCE we could perhaps do something like
>the following in find_obviously_necessary_stmts:
> for every basic block in pdom order
> for every statement from bb.end to bb.head
> if the statement is a store to A
> mark it inherently necessary if A needs to live in memory
> and it is not post-dominatored by another store
> and other DSE requirements are met.
>Is this feasible? I have to admit I don't know how DSE typically
>works and I couldn't find an algorithm. But something like this
>would be very helpful I think.
You could probably do a more limited form which ignored PHI nodes
but I really don't think you're going to find a terribly large amount
The obvious way to evaluate would be to run cddce again after dse
and see if it finds anything.