From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31531 invoked by alias); 1 Apr 2009 14:10:55 -0000 Received: (qmail 29184 invoked by alias); 1 Apr 2009 14:10:39 -0000 Date: Wed, 01 Apr 2009 14:10:00 -0000 Message-ID: <20090401141039.29183.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenther at suse dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-04/txt/msg00038.txt.bz2 ------- Comment #5 from rguenther at suse dot de 2009-04-01 14:10 ------- Subject: Re: [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout On Wed, 1 Apr 2009, jakub at gcc dot gnu dot org wrote: > ------- Comment #3 from jakub at gcc dot gnu dot org 2009-04-01 14:00 ------- > Even for live range analysis of the vars that must go into stack the block info > needs to be used, otherwise once address of a stack var escapes, you'd have to > assume it is live almost till the end of the function (at least live on any > function calls that might see it through global state, or global ptr > dereferences etc.). Using the block info, you can find out that: > { > char buf[10]; > foo (buf); > bar (); > } > baz (); > in baz () call the buf var doesn't need to be live anymore. At least short > term I think it would be best just to walk the function to be expanded, look at > all gimple_block BLOCKs referenced and note which originally non-overlapping > BLOCKs are indeed still non-overlapping after the tree passes and don't > consider originally non-overlapping BLOCKs during stack slot sharing decisions > if they are overlapping. Note that once we use more precise alias information during RTL optimizations (via alias exports patch) avoiding stack slot sharing solely based on type-based conflicts will no longer be working. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604