This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

PATCH: handle constant-propagated functions in gprof


gprof appears to get confused in the presence of constant propagated functions
generated by GCC.

As an example consider a test program, test-ipa-cp.c, for which GCC generates
constant propagated functions:
> int
> foo (int a, int b)
> {
>   if (!b) return 0;
>   if (!a)
>       return 2 * b + foo (a, b - 1)/4;
>   else
>     return 2 * -b + foo (a, b - 1)/4;
> }
> 
> int
> main (void)
> {
>   int i, a = 0;
>   for (i = 0; i < 20000; i++)
>     {
>       a += foo (0, i);
>     }
>   return a;
> }

Build, run, and profile it (I've tried this with trunk binutils, and GCC 4.6 &
GCC 4.7):

  i686-pc-linux-gnu-gcc -pg -O3 test-ipa-cp.c -o test-ipa-cp
  ./test-ipa-cp
  i686-pc-linux-gnu-gprof test-ipa-cp gmon.out

Output from gprof suggests that the majority of execution time is spent in
frame_dummy:
> index % time    self  children    called     name
>                             39986001             frame_dummy [1]
> [1]    100.0    0.46    0.00       0+39986001 frame_dummy [1]
>                              39986001             frame_dummy [1]
> -----------------------------------------------


With this patch the output correctly shows foo.constprop.0:
> index % time    self  children    called     name
>                              39986001             foo.constprop.0 [1]
> [1]    100.0    0.52    0.00       0+39986001 foo.constprop.0 [1]
>                              39986001             foo.constprop.0 [1]
> -----------------------------------------------

I believe at one point such functions were suffixed by ".clone.N" which gprof
handles specially. However it appears when this was changed to .constprop.N
gprof was never updated to handle this.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44324

This patch handles .constprop.N in the same way as .clone.N. I've left the
.clone.N code alone so gprof can correctly handle executables generated by
versions of older GCC.

I don't have commit access, so if this is acceptable perhaps someone could
commit it for me.

2012-09-20  Joe Seymour  <jseymour@codesourcery.com>

	* corefile.c (core_sym_class): Allow for ".constprop.N" cloned
	functions.

Index: corefile.c
===================================================================
RCS file: /cvs/src/src/gprof/corefile.c,v
retrieving revision 1.44
diff -u -r1.44 corefile.c
--- corefile.c	6 Mar 2012 13:54:59 -0000	1.44
+++ corefile.c	20 Sep 2012 08:54:23 -0000
@@ -396,11 +396,17 @@
 	  int digit_seen = 0;
 #define CLONE_NAME      ".clone."
 #define CLONE_NAME_LEN  strlen (CLONE_NAME)
+#define CONSTPROP_NAME      ".constprop."
+#define CONSTPROP_NAME_LEN  strlen (CONSTPROP_NAME)
 	
 	  if (strlen (name) > CLONE_NAME_LEN
 	      && strncmp (name, CLONE_NAME, CLONE_NAME_LEN) == 0)
 	    name += CLONE_NAME_LEN - 1;

+	  else if (strlen (name) > CONSTPROP_NAME_LEN
+	      && strncmp (name, CONSTPROP_NAME, CONSTPROP_NAME_LEN) == 0)
+	    name += CONSTPROP_NAME_LEN - 1;
+
 	  for (name++; *name; name++)
 	    if (digit_seen && *name == '.')
 	      break;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]