-----Original Message----- From: Jeff Law [mailto:l...@redhat.com] Sent: Thursday, August 20, 2015 1:13 AM To: Ajit Kumar Agarwal; Richard Biener Cc: GCC Patches; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: [Patch,tree-optimization]: Add new path Splitting pass on tree ssa representation
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? I meant there are more Deja GNU testcases passes with the path splitting changes. > > 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. Thanks & Regards Ajit Jeff
