On Fri, Aug 14, 2015 at 6:10 AM, Jeff Law <l...@redhat.com> wrote:
> On 07/28/2015 03:38 AM, Bin Cheng wrote:
>>
>> Hi,
>> For now, SCEV may compute iv base in the form of "(signed T)((unsigned
>> T)base + step))".  This complicates other optimizations/analysis depending
>> on SCEV because it's hard to dive into type conversions.  For many cases,
>> such type conversions can be simplified with additional range information
>> implied by loop initial conditions.  This patch does such simplification.
>> With simplified iv base, loop niter analysis can compute more accurate
>> bound
>> information since sensible value range can be derived for "base+step".
>> For
>> example, accurate loop bound&may_be_zero information is computed for cases
>> added by this patch.
>> The code is actually borrowed from loop_exits_before_overflow.  Moreover,
>> with simplified iv base, the second case handled in that function now
>> becomes the first case.  I didn't remove that part of code because it
>> may(?)
>> still be visited in scev analysis itself and simple_iv isn't an interface
>> for that.
>>
>> Is it OK?
>>
>> Thanks,
>> bin
>>
>> 2015-07-28  Bin Cheng  <bin.ch...@arm.com>
>>
>>         * tree-ssa-loop-niter.c (tree_simplify_using_condition): Export
>>         the interface.
>>         * tree-ssa-loop-niter.h (tree_simplify_using_condition): Declare.
>>         * tree-scalar-evolution.c (simple_iv): Simplify type conversions
>>         in iv base using loop initial conditions.
>>
>> gcc/testsuite/ChangeLog
>> 2015-07-28  Bin Cheng  <bin.ch...@arm.com>
>>
>>         * gcc.dg/tree-ssa/loop-bound-2.c: New test.
>>         * gcc.dg/tree-ssa/loop-bound-4.c: New test.
>>         * gcc.dg/tree-ssa/loop-bound-6.c: New test.
>
> I have the same concerns about these tests...  Which makes me really think I
> must be mis-understanding something in the debugging output.

This patch tries to simplify SCEV base with the help of loop's initial
conditions.  The previous patch can only handle simplified SCEV base
when analyzing loop's bound information.  It's independent to the
previous one.  Actually it can be viewed as an irrelevant patch even
the previous one is proven wrong.  Of course, I need to change test
case in that way.

Thanks,
bin
>
> jeff
>

Reply via email to