-----Original Message----- From: Jeff Law [mailto:l...@redhat.com] Sent: Saturday, January 16, 2016 12:03 PM 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 01/04/2016 07:32 AM, Ajit Kumar Agarwal wrote: > > > -----Original Message----- From: Jeff Law [mailto:l...@redhat.com] > Sent: Wednesday, December 23, 2015 12:06 PM 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 12/11/2015 02:11 AM, Ajit Kumar Agarwal wrote: >> >> Mibench/EEMBC benchmarks (Target Microblaze) >> >> Automotive_qsort1(4.03%), Office_ispell(4.29%), >> Office_stringsearch1(3.5%). Telecom_adpcm_d( 1.37%), >> ospfv2_lite(1.35%). >>> I'm having a real tough time reproducing any of these results. >>> In fact, I'm having a tough time seeing cases where path splitting >>> even applies to the Mibench/EEMBC benchmarks >>> >>mentioned above. > >>> In the very few cases where split-paths might apply, the net >>> resulting assembly code I get is the same with and without >>> split-paths. > >>> How consistent are these results? > > I am consistently getting the gains for office_ispell and > office_stringsearch1, telcom_adpcm_d. I ran it again today and we see > gains in the same bench mark tests with the split path changes. > >>> What functions are being affected that in turn impact performance? > > For office_ispell: The function are Function "linit (linit, > funcdef_no=0, decl_uid=2535, cgraph_uid=0, symbol_order=2) for > lookup.c file". "Function checkfile (checkfile, funcdef_no=1, > decl_uid=2478, cgraph_uid=1, symbol_order=4)" " Function correct > (correct, funcdef_no=2, decl_uid=2503, cgraph_uid=2, symbol_order=5)" > " Function askmode (askmode, funcdef_no=24, decl_uid=2464, > cgraph_uid=24, symbol_order=27)" for correct.c file. > > For office_stringsearch1: The function is Function "bmhi_search > (bmhi_search, funcdef_no=1, decl_uid=2178, cgraph_uid=1, > symbol_order=5)" for bmhisrch.c file. >>Can you send me the pre-processed lookup.c, correct.c and bmhi_search.c? >>I generated mine using x86 and that may be affecting my ability to reproduce >>your results on the microblaze target. Looking specifically at bmhi_search.c >>and correct.c, I see they are >>going to be sensitive to the target headers. >>If (for exmaple) they use FORTIFY_SOURCE or macros for toupper. >>In the bmhi_search I'm looking at, I don't see any opportunities for the path >>splitter to do anything. The CFG just doesn't have the right shape. Again, >>that may be an artifact of how >>toupper is implemented in the system header >>files -- hence my request for the cpp output on each of the important files. Would you like me to send the above files and function pre-processed with -E option flag. Thanks & Regards Ajit Jeff
