On Thu, Apr 27, 2017 at 4:30 PM, Jeff Law <l...@redhat.com> wrote: > On 04/26/2017 06:58 AM, Richard Biener wrote: >> >> On Tue, Apr 18, 2017 at 12:44 PM, Bin Cheng <bin.ch...@arm.com> >> wrote: >>> >>> Hi, This patch handles more cheap cases in function >>> force_expr_to_var_cost, specifically, TRUNC_DIV_EXPR, BIT_AND_EXPR, >>> BIT_IOR_EXPR, RSHIFT_EXPR and BIT_NOT_EXPR. >>> >>> Is it OK? >> >> >> I wonder if using add_cost is good here. TRUNC_DIV by power of two better >> matches shift_cost, no, or div_pow2_cheap? Likewise for >> LSHIFT/RSHIFT. We do have [us]div_cost as well btw. And we have >> neg_cost. > > In an ideal world, we'd have a canoncial form and just handle hte canonical > form. But that hasn't ever really panned out for this kind of stuff in RTL > -- the decision about what is the preferred form of an expression changes > based on use context. > > I don't think these problems are as bad at the gimple level, but clearly > they still exist. > > The more we query the target, the less predictable the compiler's behavior > will be over time. It was a huge problem in RTL leading us to a point > where it became exceedingly difficult to predict how a change in a pass > would ultimately affect the performance across targets. Yeah, this is what I had in mind, but not expressed as clear as this. The patch's intention is to differentiate between expensive (div) and cheap operations.
Thanks, bin > > That led to a guiding principle that we want to avoid querying the target in > gimple as much as possible. We've relaxed that somewhat (we have to be > pragmatic), but we need to be real careful here. > > So my recommendation would be to define a set of costs for gimple and get > those as solid as we can given an "ideal" target. Only query the target for > cases where it's critical. > > > Jeff
