[tree-ssa] vdefs vs DCE

[tree-ssa] vdefs vs DCE

[law]

So can someone educate me as to why DCE has to look at VDEFs when 
trying to determine if a statement is useful?

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.

That in turn causes us to hang a bunch of VDEFs on the assignments to T1, T2
and T3.

Anyway, we go into SSA form and we have:

   T1 = "fu"
   T2 = "bar"
   T3 = "com"
   foo ("fu", "bar", "com")

[ See why I said the gimplification was rather silly? :-) ]

T1, T2 and T3 are never used again.  But because we've got those annoying
VDEFs we consider each of those statements are useful and thus they are not
removed.

So you might legitimately ask is this important.  Consider that this is
going to happen anytime we pass strings as arguments to functions!  Or
that every call to abort within gcc itself will result in two of these
stores that we can't eliminate due to their VDEFS (look at how abort
expands into fancy_abort)...


Jeff

Re: [tree-ssa] vdefs vs DCE

[Diego Novillo]

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.

Re: [tree-ssa] vdefs vs DCE

[law]

In message <1053626175.6937.30.camel@frodo.toronto.redhat.com>, Diego Novillo w
rites:
 >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")
 >}
Good.


 >I think that the reason those T.x exist is because of the type casts
 >that are going on. 
Yes.  Type casts cause us numerous problems.  It's not just in argument
lists.  They (*&@#$ us up in comparisons and just about everywhere else.
I suspect we're going to really need to re-think how we handle NOP
casting.


 >It shouldn't be hard to have GIMPLE accept type
 >casts in function arguments.  Jason?
Well, I've already got a patch which does this.  Or more correctly it allows
NOP casting in TREE_LISTs, which happens to be the biggest creator of
offending code like I noted above.

However, when I was looking at that, I realized that simpify_expr is doing
some really dumb things.  For example, if you have something like a 
NOP cast and your predicate is is_simple_val (which accepts NOP casts
on constants) simplify_expr still insists on mucking things up by
assigning the casted value to a new variable and using the new
variable whereever the cast originally was.

The root of this problem is that simplify_expr doesn't check the predicate
before simplifying.  Ugh.

And we can't check the predicate before simplifying due to how we've
defined is_simple_stmt (always returns 1, which would prevent *any*
simplification).

Ideally we'd check that the operand fits the predicate and not simplify
which would make a lot of our casting issues go away.  It might even
speed up the compiler (or it may slow it down -- I don't really know).

Arrggh.

Jeff