On Thu, Jul 28, 2016 at 2:51 PM, Bin.Cheng <amker.ch...@gmail.com> wrote:
> On Wed, Jul 27, 2016 at 11:07 AM, Richard Biener
> <richard.guent...@gmail.com> wrote:
>> On Tue, Jul 26, 2016 at 7:10 PM, Bin Cheng <bin.ch...@arm.com> wrote:
>>> Hi,
>>> This patch adds support for constraint flags in loop structure. Different
>>> to existing boolean flags which are set by niter analyzer, constraint flag
>>> is mainly set by consumers and affects certain semantics of niter analyzer
>>> APIs. Currently niter APIs affected are number_of_iterations_exit* and
>>> their callers. Constraint flags are added to support handling of possible
>>> infinite loops in GCC. One typical usecase of constraint is in vectorizer,
>>> as described in patch's comment:
>>>
>>> /* ...
>>> 1) Compute niter->assumptions by calling niter analyzer API and
>>> record it as possible condition for loop versioning.
>>> 2) Clear buffered result of niter/scev analyzer.
>>> 3) Set constraint LOOP_C_FINITE assuming the loop is finite.
>>> 4) Analyze data references. Since data reference analysis depends
>>> on niter/scev analyzer, the point is that niter/scev analysis
>>> is done under circumstance of LOOP_C_FINITE constraint.
>>> 5) Version the loop with assumptions computed in step 1).
>>> 6) Vectorize the versioned loop in which assumptions is guarded to
>>> be true.
>>> 7) Update constraints in versioned loops so that niter analyzer
>>> in following passes can use it.
>>>
>>> Note consumers are usually the loop optimizers and it is consumers'
>>> responsibility to set/clear constraints correctly. Failing to do
>>> that might result in hard to track bugs in niter/scev analyzer. */
>>>
>>> Next patch will use constraint to vectorize possible infinite loop by
>>> versioning, I would also expect possible infinite loops (loops with
>>> assumptions) can be handled by more optimizers. This patch itself doesn't
>>> change GCC behavior, bootstrap and test on x86_64. Any comments?
>>
>> + Note consumers are usually the loop optimizers and it is consumers'
>> + responsibility to set/clear constraints correctly. Failing to do
>> + that might result in hard to track bugs in niter/scev analyzer. */
>>
>> "in hard to track down bugs in niter/scev consumers"
>>
>> +static inline void
>> +loop_constraint_clr (struct loop *loop, unsigned c)
>> +{
>>
>> use _clear (similar to loops_state_clear). Function comments missing.
>>
>> I think we want to copy constraints in copy_loop_info.
>>
>> Please place the 'constraints' field in struct loop somewhere better,
>> between two pointers we have 4 bytes wasted on a 64bit arch.
>> Maybe you can group all bools and put constraints next to safelen
>> (yeah, we'd still waste some padding, not sure if we want to turn
>> the bools and estimate_state into a bitfield).
>>
>> It would be nice to document the constraints in doc/loop.texi.
>>
>> Ok with that changes.
> Hi,
> Attachment is the updated patch with comments addressed.
Ok.
Thanks,
Richard.
> Thanks,
> bin
>
>
> 2016-07-27 Bin Cheng <bin.ch...@arm.com>
>
> * cfgloop.h (struct loop): New field constraints.
> (LOOP_C_INFINITE, LOOP_C_FINITE): New macros.
> (loop_constraint_set, loop_constraint_clr, loop_constraint_set_p): New
> functions.
> * cfgloop.c (alloc_loop): Initialize new field.
> * cfgloopmanip.c (copy_loop_info): Copy constraints.
> * tree-ssa-loop-niter.c (number_of_iterations_exit_assumptions):
> Adjust niter analysis wrto loop constraints.
> * doc/loop.texi (@node Number of iterations): Add description for loop
> constraints.
