Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation

[Jeff Law <law@redhat.com>]

On 11/13/2015 03:13 AM, Richard Biener wrote:

>> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
>> index 34d2356..6613e83 100644
>> --- a/gcc/Makefile.in
>> +++ b/gcc/Makefile.in
>> @@ -1474,6 +1474,7 @@ OBJS = \
>>          tree-ssa-loop.o \
>>          tree-ssa-math-opts.o \
>>          tree-ssa-operands.o \
>> +       tree-ssa-path-split.o \
>
> gimple-ssa-path-split please.
Agreed.   I'll make that change for Ajit.


>
>>          tree-ssa-phionlycprop.o \
>>          tree-ssa-phiopt.o \
>>          tree-ssa-phiprop.o \
>> diff --git a/gcc/common.opt b/gcc/common.opt
>> index 757ce85..3e946ca 100644
>> --- a/gcc/common.opt
>> +++ b/gcc/common.opt
>> @@ -2403,6 +2403,10 @@ ftree-vrp
>>   Common Report Var(flag_tree_vrp) Init(0) Optimization
>>   Perform Value Range Propagation on trees.
>>
>> +ftree-path-split
>
> fsplit-paths
And this plus related variable name fixes and such.


>>
>> +@item -ftree-path-split
>> +@opindex ftree-path-split
>> +Perform Path Splitting on trees.  When the two execution paths of a
>> +if-then-else merge at the loop latch node, try to duplicate the
>> +merge node into two paths. This is enabled by default at @option{-O2}
>> +and above.
>> +
>
> I think if we go into the detail of the transform we should mention the
> effective result (creating a loop nest with disambiguation figuring out
> which is the "better" inner loop).
It no longer creates a loop nest.  The overall shape of the CFG is 
maintained.  ie, we still have a single simple latch for the loop.  The 
blocks we create are internal to the loop.

I always struggle with the right level at which to document these 
options.   I'll take a look at this for Ajit.

BTW Do we have an API for indicating that new blocks have been added to 
a loop?  If so, then we can likely drop the LOOPS_NEED_FIXUP.


>
>>   @item -fsplit-ivs-in-unroller
>>   @opindex fsplit-ivs-in-unroller
>>   Enables expression of values of induction variables in later iterations
>> diff --git a/gcc/opts.c b/gcc/opts.c
>> index 9a3fbb3..9a0b27c 100644
>> --- a/gcc/opts.c
>> +++ b/gcc/opts.c
>> @@ -509,6 +509,7 @@ static const struct default_options
>> default_options_table[] =
>>       { OPT_LEVELS_2_PLUS, OPT_fisolate_erroneous_paths_dereference, NULL, 1
>> },
>>       { OPT_LEVELS_2_PLUS, OPT_fipa_ra, NULL, 1 },
>>       { OPT_LEVELS_2_PLUS, OPT_flra_remat, NULL, 1 },
>> +    { OPT_LEVELS_2_PLUS, OPT_ftree_path_split, NULL, 1 },
>
> Is this transform a good idea for -Os?
In general, no because of the block duplication.

jeff