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

[Jeff Law]

On 01/18/2016 02:13 AM, Ajit Kumar Agarwal wrote:


-----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.
That would be perfect.  I'm on the road the latter half of the week into 
early next week -- the long flights might be a good time for me to stare 
at the dumps and tweak the heuristic a bit.

jeff