On Thu, Apr 27, 2017 at 5:45 PM, Bin.Cheng <amker.ch...@gmail.com> wrote: > 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.
Ok. Let's go with the patch as-is then and if possible change the code to use estimate_num_insns instead (but I guess we may end up comparing the cost to the address costs we compute more exactly?) Richard. > 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
