On March 16, 2015 7:15:23 PM GMT+01:00, Jeff Law <l...@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
