From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26471 invoked by alias); 17 Oct 2004 19:48:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 26463 invoked from network); 17 Oct 2004 19:48:51 -0000 Received: from unknown (HELO dberlin.org) (68.164.203.246) by sourceware.org with SMTP; 17 Oct 2004 19:48:51 -0000 Received: from [127.0.0.1] (HELO [127.0.0.1]) by dberlin.org (CommuniGate Pro SMTP 4.2.1) with ESMTP-TLS id 7397510; Sun, 17 Oct 2004 15:48:51 -0400 Subject: Re: [patch] for PR 18040 From: Daniel Berlin To: Zdenek Dvorak Cc: Richard Kenner , gcc-patches@gcc.gnu.org In-Reply-To: <20041017194615.GA23959@atrey.karlin.mff.cuni.cz> References: <10410171944.AA00989@vlsi1.ultra.nyu.edu> <20041017194615.GA23959@atrey.karlin.mff.cuni.cz> Content-Type: text/plain Date: Sun, 17 Oct 2004 20:01:00 -0000 Message-Id: <1098042531.31401.12.camel@dberlin.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2004-10/txt/msg01404.txt.bz2 On Sun, 2004-10-17 at 21:46 +0200, Zdenek Dvorak wrote: > Hello, > > > is_gimple_addressable uses handled_component_p to determine whether its > > operand is a component reference. However handled_component_p allows > > also NOP_EXPRs and CONVERT_EXPRs. This in turn makes SRA believe that > > ((cast) var).field is valid gimple (since "(cast) var" passes > > is_gimple_addressable), which causes crash later. > > > > Can you explain this more? I very much think it's going in the wrong > > direction to not use handled_component_p. If we don't want to view a > > an expression as being a component that's handled, we should change > > handled_component_p. But right now, what you show above in valid GIMPLE. > > Perhaps there's a bug elsewehre. > > no, it is not valid gimple, since it does not match grammar as > described in documentation. Also considering "(cast) something" > to be addressable is a bit weird by itself. > > Of course feel free to propose to extend gimple for this if you think it > would be useful; handling the no-op casts in addresses would not be a > problem from optimizations point of view. Except then the optimizers would have to start breaking apart expressions and stripping off nops again where they didn't matter, wouldn't they? Right now the only time you see a nop_expr is at the top level of a RHS. Changing gimple to allow casts in any other part of the tree is a very bad idea, IMHO. > > Zdenek --