Re: [tree-ssa] vdefs vs DCE

[Diego Novillo <dnovillo at redhat dot com>]

On Thu, 2003-05-22 at 10:44, law@redhat.com wrote:

> So can someone educate me as to why DCE has to look at VDEFs when 
> trying to determine if a statement is useful?
> 
That's the only reason, actually.  I was today considering not adding
the VDEFs at all, but we would miss things like:

     1. {
     2.   int *p, b, c;
     3. 
     4.   p = <&b or &c>
     5.   *p = b;
     6.   b = 3;
     7.   c = 2;
     8.   return b;
     9. }

Even though 'c' is aliased, the assignment to 'c' at line 7 is dead.  If
we totally ignored statements with aliased references, I think things
would work (it would certainly have some compile time improvements). 
However, we would miss a few opportunities like this one.

> The reason I'm asking is doing so causes DCE to keep around a fair number
> of stores which are trivially shown to be unnecessary.
> 
> Let's consider gimplification of this code
> 
>    foo ("fu", "bar", "com")
> 
> We'll gimplify that into something like
> 
>    T1 = "fu"
>    T2 = "bar"
>    T3 = "com"
>    foo (T1, T2, T3)
> 
> [ Frankly that seems rather silly as well -- but I'll postpone that argument
>   for another day. ]
> 
> 
> Now since T1, T2 and T3 are used as arguments, we consider the memory
> they point to as modified by the call itself and we consider *T1, *T2 and *T3
> as aliasing global memory.
> 
I fixed this particular idiocy with the new changes to remove
INDIRECT_REFs as variables.  In my local tree, I get this out of DCE:

foo ()
{
  (void)0;
  (void)0;
  (void)0;
  (void)0;
  (void)0;
  (void)0;

  bar ((char *)"fu", (char *)"bar", (char *)"com")
}

I think that the reason those T.x exist is because of the type casts
that are going on.  It shouldn't be hard to have GIMPLE accept type
casts in function arguments.  Jason?


Diego.