This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa]: Dump file option names and small DCE fix
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 18 Sep 2002 23:27:38 -0400
- Subject: Re: [tree-ssa]: Dump file option names and small DCE fix
On Wednesday, September 18, 2002, at 09:20 PM, Diego Novillo wrote:
I am too by now.
On Wed, 18 Sep 2002, Daniel Berlin wrote:
In trying out DCE, I noticed that it fcloses the dump_file in the same
if block it opens it in, so nothing besides a pre-dce dump gets
Thanks. This is OK.
I fixed this, and took the time to canonicalize the dump
option/file/enum names as we talked about earlier.
They now match the -f option. So we have -ftree-ssa-ccp and
-fdump-tree-ssa-ccp, and the enum is TDI_ssa_ccp.
You know, I've been thinking about this whole naming convention.
After having typed -fdump-tree-...blah...blah like a million
times, I'm finding these long names really annoying.
In fact, my motivation for this patch was that i kept getting the names
of the dump options wrong because they didn't match the passes.
Would it break your heart if we removed the ssa prefix from all
My fingers are tired of it too.
After all, we already know that these passes are
working on SSA, and to the end-user the fact that they are using
SSA or not is irrelevant. If, at a later date, we implement say
a DCE pass that doesn't use SSA, then we can name it differently.
What I propose is:
-ftree-ssa => Goes away. Indirectly enabled by the
-ftree-ssa-ccp => -ftree-ccp
-ftree-ssa-dce => -ftree-dce
-ftree-ssa-pre => -ftree-pre
Similarly, we drop 'ssa' from the -fdump-tree switches.
Works for me.
I'll just modify it as suggested.
Want me to repost, and let you look at it again, or just commit it?
After doing this, on a simple example, DCE eliminated everything.
The reason was that it doesn't consider return_stmt's inherently
Hmm, I think this is wrong.
i didn't think much about it, i just wanted to see what would happen,
and it did the right thing, so i figured it might be right.
I had a nagging feeling
A return statement shouldn't be
Sure. I'll also remove the change from the patch.
By making the return inherently necessary, you trick DCE into
leaving the if() that we already know is impossible. You may
have found a bug in the DFA information that led DCE to consider
Could you post the testcase?
It's just the example steve posted yesterday:
int bla, foo, bar;
bla = 1;
foo = 2*bla;
bar = 2*bla+1;
bla = 1;
If you *don't* consider the return_stmt's necessary, it transforms it
which is wrong anyway (besides the obvious), since the first return is