Re: [tree-ssa]: Dump file option names and small DCE fix

[Daniel Berlin <dberlin at dberlin dot org>]

On Wednesday, September 18, 2002, at 09:20  PM, Diego Novillo wrote:

> 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 
> > printed
> > to it.
> 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.
I am too by now.
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
> these names?
Nah.
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
> 			   other switches.
> -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
> > necessary.
> Hmm, I think this is wrong.
Maybe.
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
> inherently necessary.
>  Consider:
>
> 	if (impossible)
> 	  return;
>
> 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
> it unnecessary.
>  Could you post the testcase?
Sure.  I'll also  remove the change from the patch.

It's just the example steve posted yesterday:
int main()
{
        int bla, foo, bar;

        bla = 1;
        foo = 2*bla;
        bar = 2*bla+1;
        goto waffle;
        return bar;
waffle:
        bla = 1;
        return bar;
}


If you *don't* consider the return_stmt's necessary, it transforms it 
into:
{
  int bla;
  int foo;
  int bar;
  int T.1;
  goto waffle;
  return bar;
  waffle:
  return bar;
}
which is wrong anyway (besides the obvious), since the first return is 
useless.

> Thanks.  Diego.