Re: [tree-ssa] vdefs vs DCE

[law at redhat dot com]

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