From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25895 invoked by alias); 22 May 2003 18:21:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 25884 invoked from network); 22 May 2003 18:21:42 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 22 May 2003 18:21:42 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h4MILgH29622 for ; Thu, 22 May 2003 14:21:42 -0400 Received: from speedy.slc.redhat.com (vpn50-29.rdu.redhat.com [172.16.50.29]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h4MILdI03696; Thu, 22 May 2003 14:21:39 -0400 Received: from redhat.com (law@localhost) by speedy.slc.redhat.com (8.12.8/8.12.8/Submit) with ESMTP id h4MILOXD005600; Thu, 22 May 2003 12:21:24 -0600 Message-Id: <200305221821.h4MILOXD005600@speedy.slc.redhat.com> X-Authentication-Warning: speedy.slc.redhat.com: law owned process doing -bs To: Diego Novillo cc: Andrew Macleod , "gcc@gcc.gnu.org" Reply-To: law@redhat.com Subject: Re: [tree-ssa] vdefs vs DCE In-Reply-To: Your message of "22 May 2003 13:56:15 EDT." <1053626175.6937.30.camel@frodo.toronto.redhat.com> From: law@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 May 2003 18:22:00 -0000 X-SW-Source: 2003-05/txt/msg02033.txt.bz2 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