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 the old behavior is worth preserving. Richard. > Thanks, > bin
