From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24582 invoked by alias); 9 Oct 2007 06:01:56 -0000 Received: (qmail 24569 invoked by uid 22791); 9 Oct 2007 06:01:55 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 Oct 2007 06:01:52 +0000 Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id l9961gQ5028805; Tue, 9 Oct 2007 07:01:43 +0100 Received: from smtp.corp.google.com (spacemonkey1.corp.google.com [192.168.120.115]) by zps37.corp.google.com with ESMTP id l9961fRF031622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Oct 2007 23:01:41 -0700 Received: from localhost.localdomain.google.com (adsl-76-249-168-94.dsl.pltn13.sbcglobal.net [76.249.168.94]) (authenticated bits=0) by smtp.corp.google.com (8.13.8/8.13.8) with ESMTP id l9961el4027142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Oct 2007 23:01:41 -0700 To: "Uros Bizjak" Cc: "GCC Patches" , zadeck@naturalbridge.com Subject: Re: [PATCH, rtl-optimization]: Fix PR rtl-optimization/33638 References: <5787cf470710080514m2edaae59ma1f21c008de64800@mail.gmail.com> From: Ian Lance Taylor Date: Tue, 09 Oct 2007 06:01:00 -0000 In-Reply-To: <5787cf470710080514m2edaae59ma1f21c008de64800@mail.gmail.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-10/txt/msg00463.txt.bz2 "Uros Bizjak" writes: > 2007-10-08 Uros Bizjak > > PR rtl-optimization/33638 > * explow.c (memory_address): When -fforce-addr is in effect, > do not force addresses using virtual_outgoing_args_rtx or > stack_pointer_rtx to a temporary register. It's hard for me to be entirely happy with this patch. Some processors don't have register offset addressing, so all access to the stack is done by copying and adding registers. It seems to me that such processors might have trouble with dse.c as currently written. On the other hand, -fforce-addr is meaningful for stack addresses, especially on architectures with only small stack pointer offsets or for which register direct instructions are smaller than register offset addresses. If I understand the problem correctly, the issue is that the address of a function argument was loaded into a register. A later store using that register was not noticed as being for a function argument, and was eliminated as dead although it was not. All would be well if you knew that the store was for a function argument. And, of course, the issue only arises for const functions, as for a non-const function all stores are live. There is special code in calls.c to mark the stack usage of const functions: around line 2700, in expand_call. It seems to me that if store_one_arg comes up with a different address, because it calls memory_address, you should put that address also in CALL_INSN_FUNCTION_USAGE. That ought to fix the immediate problem as well. I think there is still a lurking issue, which is that in principle dse.c really needs to record which stores may be for function arguments. I don't see a really good way to do that, though of course it could be done by setting and propagating a register flag. Ian