Re: [PATCH GCC]Simplify interface for simplify_using_initial_conditions

["Bin.Cheng" <amker dot cheng at gmail dot com>]

On Thu, Aug 4, 2016 at 1:48 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Thu, Aug 4, 2016 at 10:40 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>> On Wed, Aug 3, 2016 at 11:17 PM, Jeff Law <law@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.cheng@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?

Thanks,
bin

Attachment: always-expand-cond-expr-20160803.txt
Description: Text document