------- 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