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