This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposal for another approach for Loop transformation with conditional in Loops.
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>,Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>,"gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Cc: Vinod Kathail <vinodk at xilinx dot com>,Shail Aditya Gupta <shailadi at xilinx dot com>,Vidhumouli Hunsigida <vidhum at xilinx dot com>,Nagaraju Mekala <nmekala at xilinx dot com>
- Date: Mon, 16 Mar 2015 19:28:22 +0100
- Subject: Re: Proposal for another approach for Loop transformation with conditional in Loops.
- Authentication-results: sourceware.org; auth=none
- References: <BN1BFFO11OLC00152B62B175CC7F96E1424AE050 at BN1BFFO11OLC001 dot protection dot gbl> <55071DBB dot 9010902 at redhat dot com>
On March 16, 2015 7:15:23 PM GMT+01:00, Jeff Law <law@redhat.com> wrote:
>On 03/14/15 22:40, Ajit Kumar Agarwal wrote:
>> Hello All:
>>
>> I am proposing the new approach to Loop transformation as given below
>in the example For the loops with
>> conditional expression inside the Loops. The Loop body should be
>reducible control flow graph. The iteration
>> space is partitioned into different spaces for which either the
>cond_expr is true or cond_expr is false. The
>> evaluation of cond_expr for the partitioned iteration spaces can be
>determined statically. For the partitioned
>> iterations and based on the analysis of cond_expr on the partitioned
>iterations spaces the Loops in fig (a) will
>> be transformed to Loops in fig (b).
>>
>> for the iteration spaces of the conditional inside the loop is live
>in at the entry of the cond_expr and Live out
>> the Control flow graph is topological ordered with the basic blocks
>for the conditional CFG and the partitioned
>> iteration spaces can be formed for which the spaces can be true for
>conditional expr and false and unknown.
>>
>> Based on the above info and analysis the Loop of Fig (a) will be
>transformed to Loop Fig (b).
>>
>> This is much more optimized code as compared to the performance. The
>cases will be triggered for SPEC
>> Benchmarks. Loops is partitioned to different version with different
>iteration spaces. Optimized in the presence
>> Of the transformed generation of the loops without conditional.
>I fail to see how this is dramatically different than unswitching.
>You
>pull the condition out (it has to be loop invariant), then have two
>instances of the loop, one for the THEN, the other for the ELSE. You
>obviously select one or the other based on the condition of V.
>
>Specific examples might be helpful in understanding how you see this as
>
>different than unswitching.
I think he is proposing loop splitting incase there are conditions in The IV itself. Obviously those are not loop invariant.
Richard.
>jeff