From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5642 invoked by alias); 13 May 2003 16:30:03 -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 5592 invoked from network); 13 May 2003 16:30:02 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 13 May 2003 16:30:02 -0000 Received: from localhost (tornado.toronto.redhat.com [172.16.14.228]) by touchme.toronto.redhat.com (Postfix) with ESMTP id AEC00800030; Tue, 13 May 2003 12:30:01 -0400 (EDT) Subject: Re: Dead-code elimination can't remove string copy insns? From: Diego Novillo To: Zack Weinberg Cc: Michael Matz , "gcc@gcc.gnu.org" In-Reply-To: <87el32om7e.fsf@egil.codesourcery.com> References: <87el32om7e.fsf@egil.codesourcery.com> Content-Type: text/plain Organization: Red Hat Canada Message-Id: <1052843397.27232.380.camel@frodo.toronto.redhat.com> Mime-Version: 1.0 Date: Tue, 13 May 2003 16:30:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg01326.txt.bz2 On Tue, 2003-05-13 at 12:17, Zack Weinberg wrote: > Michael Matz writes: > > >> but the alias information should be sufficient to see that the memory > >> region being written into is on the stack, and unused past this insn, > >> hence the store is dead and can be deleted. > > > > It should, but we don't do that currently. > > Do you have a sense for how hard this would be to implement? Is it > something that's done on tree-ssa, so there's no point adding it in > mainline? Will Naveen's stack-slot allocator help? > If you show me the original source code I could tell you. Once things are in RTL form, it's difficult for me to trace them back into trees. There's also the situation in which we have dead code at the RTL level that it's impossible to detect at the tree level (e.g. address arithmetic for array references). Diego.