[PATCH PR71437/V2]Simplify cond with assertions in threading

[Bin.Cheng]

On Fri, Feb 17, 2017 at 3:40 AM, Jeff Law <law@redhat.com> wrote:
> On 02/14/2017 03:05 AM, Bin Cheng wrote:
>>
>> Hi,
>> This is the second try fixing PR71437.  The old version patch tried to fix
>> issue in VRP but it requires further non-trivial change in VRP,
>> specifically, to better support variable value ranges.  This is not
>> appropriate at stage 4.  Alternatively, this patch tries to fix issue by
>> improving threading.  It additionally simplifies condition by using
>> assertion conditions.
>>
>> Bootstrap and test on x86_64 and AArch64.  Is it OK?
>>
>> Thanks,
>> bin
>>
>> 2017-02-13  Bin Cheng  <bin.cheng@arm.com>
>>
>>         PR tree-optimization/71437
>>         * tree-ssa-loop-niter.c (tree_simplify_using_condition): Only
>>         expand condition if new parameter says so.  Also change it to
>>         global.
>>         * tree-ssa-loop-niter.h (tree_simplify_using_condition): New
>>         declaration.
>>         * tree-ssa-threadedge.c (tree-ssa-loop-niter.h): New include file.
>>         (simplify_control_stmt_condition_1): Simplify condition using
>>         assert conditions.
>>
>> gcc/testsuite/ChangeLog
>> 2017-02-13  Bin Cheng  <bin.cheng@arm.com>
>>
>>         PR tree-optimization/71437
>>         * gcc.dg/tree-ssa/pr71437.c: New test.
>>
> So following up.  We're not going to get anywhere using the ranges in VRP.
> As Bin noted in the V1 patch, VRP prefers a useless range with constant
> bounds when a symbolic range would be better.  Thus the callbacks into VRP
> are doomed to failure.
>
> Bin's patch works around this by using the ASSERT_EXPRs to recover the
> symbolic range.  So it's a bit of a hack, but not a terrible one.  If we
> want to continue this path, we might still look for ways to avoid
> simplify_using_condition.
>
> One idea would be to go ahead and record the equivalence from the
> ASSERT_EXPR into the expression hash table and use the expression hash table
> to simplify the condition.  We didn't have that ability in the past, but
> should now after the refactorings from last year.
>
> It's slightly related to some ideas I've got around tackling 78496.
>
> I'm in/out of the office for until the 27th semi-randomly.  I'll try to poke
> at this while on the road.
Thanks for helping, I will hold this patch and let you work out a
generic fix in threading.

Thanks,
bin
>
> Jeff
>
>