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.

Thanks,
bin

Reply via email to