From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28859 invoked by alias); 10 Dec 2008 22:03:55 -0000 Received: (qmail 21019 invoked by alias); 10 Dec 2008 22:02:28 -0000 Date: Wed, 10 Dec 2008 22:03:00 -0000 Message-ID: <20081210220228.21017.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/32044] [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rakdver at kam dot mff dot cuni dot cz" 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: 2008-12/txt/msg01086.txt.bz2 ------- Comment #57 from rakdver at kam dot mff dot cuni dot cz 2008-12-10 22:02 ------- Subject: Re: [4.3/4.4 Regression] final value replacement too aggressive for e.g. targets with no native div/mod insns > I think Zdenek is right in comment #54: We should reincarnate > expression_expensive_p in some form such that it takes into account (or makes a > reasonable guess about) which instructions are particularly expensive. > Apparently, the old cost check was too conservative (it tested the expression > cost against spill cost, ignoring further optimization opportunities). So we > need to test for something else than before. > > Maybe we should not replace if the final value is not a constant? That is way too conservative (replacing the final values like say "n + 1" should usually be profitable). > Or if it is an expression involving div/mod? That is what I currently plan to do. > Can we test somehow how many insns the final > value replacement computation would take I think that has the same problems as the original solution (it is not possible to find a bound that would both prevent expensive things to be moved out and to allow the non-expensive ones, as the exact costs are target-specific and we are not estimating them precisely enough). > (maybe re-use the inliner heuristics)? That would be difficult, as estimate_num_insns works on gimple statements, not on expressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044