From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10078 invoked by alias); 9 Mar 2003 15:56:00 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 10063 invoked by uid 71); 9 Mar 2003 15:56:00 -0000 Date: Sun, 09 Mar 2003 15:56:00 -0000 Message-ID: <20030309155600.10062.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Jim Wilson Subject: Re: middle-end/9997: Coelesce stack slots for disjoint scopes. Reply-To: Jim Wilson X-SW-Source: 2003-03/txt/msg00428.txt.bz2 List-Id: The following reply was made to PR middle-end/9997; it has been noted by GNATS. From: Jim Wilson To: gcc-gnats@gcc.gnu.org Cc: Subject: Re: middle-end/9997: Coelesce stack slots for disjoint scopes. Date: Sun, 09 Mar 2003 10:52:33 -0500 I believe we have tried this in the past, and ran into aliasing problems. Suppose you have two variables of different types defined in different scopes. Suppose the scheduler reorders instructions causing the scopes to overlap. Now you do an alias test, and the alias code says that two references can't possibly alias because they have different types, but they do, because they were allocated to the same stack slot. You can't rely on a test for the same address, because we may have lost address info in the RTL. We have different and better alias code now, so perhaps there is a way to address this. Maybe if we add scope nesting level info to the alias info, and then assume that locals alias if they are in different scopes with a common parent, and neither is a parent of the other. Jim