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.
Jeff
