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

[Daniel Berlin]

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.