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

[Jeff Law]

On 08/15/2015 11:01 AM, Ajit Kumar Agarwal wrote:
> All:
>
> Please find the updated patch with suggestion and feedback
> incorporated.
>
> Thanks Jeff and Richard for the review comments.
>
> Following changes were done based on the feedback on RFC comments.
> and the review for the previous patch.
>
> 1. Both tracer and path splitting pass are separate passes so  that
> two instances of the pass will run in the end, one doing path
> splitting and one doing  tracing, at different times in the
> optimization pipeline.
I'll have to think about this.  I'm not sure I agree totally with
Richi's assertion that we should share code with the tracer pass, but
I'll give it a good looksie.



> 2. Transform code is shared for tracer and path splitting pass. The
> common code in extracted in a given function transform_duplicate And
> place the function in tracer.c and the path splitting pass uses the
> transform code.
OK.  I'll take a good look at that.


> 3. Analysis for the basic block population and traversing the basic
> block using the Fibonacci heap is commonly used. This cannot be
> Factored out into new function as the tracer pass does more analysis
> based on the profile and the different heuristics is used in tracer
> And path splitting pass.
Understood.


> 4. The include headers is minimal and presence of what is required
> for the path splitting pass.
THanks.


> 5. The earlier patch does the SSA updating  with replace function to
> preserve the SSA representation required to move the loop latch node
> same as join Block to its predecessors and the loop latch node is
> just forward block. Such replace function are not required as
> suggested by the Jeff. Such replace Function goes away with this
> patch and the transformed code is factored into a given function
> which is shared between tracer and path splitting pass.
Sounds good.

>
> Bootstrapping with i386 and Microblaze target works fine. No
> regression is seen in Deja GNU tests for Microblaze. There are
> lesser failures. Mibench/EEMBC benchmarks were run for Microblaze
> target and the gain of 9.3% is seen in rgbcmy_lite the EEMBC
> benchmarks.
What do you mean by there are "lesser failures"?  Are you saying there 
are cases where path splitting generates incorrect code, or cases where 
path splitting produces code that is less efficient, or something else?

>
> SPEC 2000 benchmarks were run with i386 target and the following
> performance number is achieved.
>
> INT benchmarks with path splitting(ratio) Vs INT benchmarks without
> path splitting(ratio) = 3661.225091 vs 3621.520572
That's an impressive improvement.

Anyway, I'll start taking a close look at this momentarily.

Jeff