From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3068 invoked by alias); 7 Mar 2012 13:31:50 -0000 Received: (qmail 3054 invoked by uid 22791); 7 Mar 2012 13:31:49 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Mar 2012 13:31:36 +0000 From: "scovich at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/50346] Function call foils VRP/jump-threading of redundant predicate on struct member Date: Wed, 07 Mar 2012 13:31:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: alias, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: scovich at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2012-03/txt/msg00626.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346 --- Comment #6 from Ryan Johnson 2012-03-07 13:31:19 UTC --- (In reply to comment #5) > On Wed, 12 Oct 2011, scovich at gmail dot com wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346 > > > > --- Comment #4 from Ryan Johnson 2011-10-12 12:40:25 UTC --- > > (In reply to comment #3) > > > Well, it's a tree optimization issue. It's simple - the local aggregate f > > > escapes the function via the member function call to baz: > > > > > > : > > > foo::baz (&f); > > > > > > and as our points-to analysis is not flow-sensitive for memory/calls this > > > causes f to be clobbered by the call to bar > > > > Is flow-sensitive analysis within single functions prohibitively expensive? All > > the papers I can find talk about whole-program analysis, where it's very > > expensive in both time and space; the best I could find (CGO'11 best paper) > > gets it down to 20-30ms and 2-3MB per kLoC for up to ~300kLoC. > > It would need a complete rewrite, it isn't integratable into the current > solver (which happens to be shared between IPA and non-IPA modes). That makes sense... Wild idea: would it be possible to annotate references as "escaped" or "not escaped yet" ? Anything global or passed into the function would be marked as escaped, while anything allocated locally would start out as not escaped; assigning to an escaped location or passing to a function would mark it as escaped if it wasn't already. The status could be determined in linear time using local information only (= scalable), and would benefit strongly as inlining (IPA or not) eliminates escape points. Alternatively (or maybe it's really the same thing?), I could imagine an SSA "operation" which "moves" the non-escaped variable into an escaped one (which happens to live at the same address) just before it escapes? That might give the same effect with no changes to the current flow-insensitive algorithm, as long as the optimizer knew how to adjust things to account for inlining.