On 08/05/2016 08:53 AM, Bin.Cheng wrote:
On Thu, Aug 4, 2016 at 1:48 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
On Thu, Aug 4, 2016 at 10:40 AM, Bin.Cheng <amker.ch...@gmail.com> wrote:
On Wed, Aug 3, 2016 at 11:17 PM, Jeff Law <l...@redhat.com> wrote:
On 08/03/2016 10:35 AM, Bin Cheng wrote:
Hi,
When I introduced parameter STOP for expand_simple_operations, I also
added it for simplify_using_initial_conditions. The STOP argument is also
passed to simplify_using_initial_conditions in
simple_iv_with_niters/loop_exits_before_overflow. After analyzing case
reported by PR72772, I think STOP expanding is only needed for
expand_simple_operations when handling IV.step in tree-ssa-loop-ivopts.c.
For other cases like calls to simplify_using_initial_condition, both cond
and expr should be expanded to check tree expression equality. This patch
does so. It simplifies interface by removing parameter STOP, also moves
expand_simple_operations from tree_simplify_using_condition_1 to its caller.
Bootstrap and test on x86_64 and AArch64. Is it OK?
Thanks,
bin
2016-08-02 Bin Cheng <bin.ch...@arm.com>
PR tree-optimization/72772
* tree-ssa-loop-niter.h (simplify_using_initial_conditions):
Delete
parameter STOP.
* tree-ssa-loop-niter.c (tree_simplify_using_condition_1): Delete
parameter STOP and update calls. Move expand_simple_operations
function call from here...
(simplify_using_initial_conditions): ...to here. Delete parameter
STOP.
(tree_simplify_using_condition): Delete parameter STOP.
* tree-scalar-evolution.c (simple_iv_with_niters): Update call to
simplify_using_initial_conditions.
OK.
jeff
Thanks for reviewing. Now I have a question about behavior of the
interface. Although by expanding both cond and expr, this patch
catches more equality cases, it always returns expanded expr even it's
not simplified, while the original behavior only returns simplified
expr (not expanded). For most use cases, it doesn't matter because we
only care if the simplified result is TRUE or FALSE, but in
computation of niter->assumption and niter->may_be_zeor, we may result
in different (expanded) expressions. Not sure how much this
difference matters. I can work on another version patch keeping the
old behavior if it worth keeping.
It might result in additional redundant code to be generated when generating
versioning conditions from assumption or maybe_zero? So yes, I think
Yes, that's the case it matters.
Hi Jeff, Richard,
Attachment is updated patch preserving the old behavior. Bootstrap
and test again. Is it OK?
OK with a ChangeLog.
Thanks,
jeff
