From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26734 invoked by alias); 13 May 2003 01:30:26 -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 26644 invoked from network); 13 May 2003 01:30:25 -0000 Received: from unknown (HELO egil.codesourcery.com) (66.92.14.122) by sources.redhat.com with SMTP; 13 May 2003 01:30:25 -0000 Received: from zack by egil.codesourcery.com with local (Exim 3.36 #1 (Debian)) id 19FOcW-0006FW-00; Mon, 12 May 2003 18:30:20 -0700 To: Dale Johannesen Cc: gcc@gcc.gnu.org Subject: Re: Dead-code elimination can't remove string copy insns? References: <731C93BE-84DC-11D7-BAEF-000393D76DAA@apple.com> From: Zack Weinberg Date: Tue, 13 May 2003 01:30:00 -0000 In-Reply-To: <731C93BE-84DC-11D7-BAEF-000393D76DAA@apple.com> (Dale Johannesen's message of "Mon, 12 May 2003 17:47:18 -0700") Message-ID: <873cjjpr9v.fsf@egil.codesourcery.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg01264.txt.bz2 Dale Johannesen writes: > On Monday, May 12, 2003, at 05:26 PM, Zack Weinberg wrote: >> Why can't anything delete these insns? I'm guessing it has something >> to do with the BLKmode memory access, 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. > > Can it tell the region's address hasn't been taken and stored somewhere? I don't know what it can or can't tell. In the initial RTL, the region's address was taken and passed to a subroutine call, but CSE deletes all of that, because it's unreachable. By the time we get to life analysis, the insn I quoted is the last one in the function, so even if someone had stored the address somewhere, using it would provoke undefined behavior. zw