Re: [Patch GCC]Support constraint flags in loop structure.

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, Jul 28, 2016 at 2:51 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
> On Wed, Jul 27, 2016 at 11:07 AM, Richard Biener
> <richard.guenther@gmail.com> wrote:
>> On Tue, Jul 26, 2016 at 7:10 PM, Bin Cheng <Bin.Cheng@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.cheng@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.