On Wed, Apr 20, 2016 at 1:56 PM, Wilco Dijkstra <wilco.dijks...@arm.com> wrote: > Richard Biener wrote: >> Better - comments below. Jakub objections to the usefulness of the transform >> remain - we do have the strlen pass that uses some global knowledge to decide >> on profitability. One could argue that for -Os doing the reverse transform >> is >> profitable? > > In what way would it get more info to decide on profitability? The transform > is > profitable unless you messed up your strlen implementation badly. > > For -Os one could do the reverse, but I don't think it is going to give a > substantial > codesize gain compared to other simple improvements, so unlikely worth it. > >>> + if (optimize_function_for_size_p (cfun)) >>> + return false; >> >> Hmm, I think we'd want a optimize_stmt_for_size_p (stmt) which >> does the right thing for the case we have a CFG (look at the BB) >> or when not (look at the function). > > Does that use the often incorrect BB probabilities? I used the function > variant on > purpose to avoid it making the wrong decision. A typical example I see is > that GCC > inlines a return sequence into an if marked with __builtin_expect (c, 0) but > not in the > hot code that follows... > >> I think you want to build a gimple_assign directly here, otherwise ... > >>... this may not reliably end up at the call stmt. > > OK, I revisit that once we've agreed how to proceed with this patch - we now > have > 3 variants...
Yeah ;) I'm currently bootstrapping/testing the patch that makes it possible to write all this in match.pd. Richard. > Wilco >
