GP32 Gp32 Gcc Profiling

[slaanesh]

I was having a look through notaz's instructions on profiling gcc generated executables for the GP2X.
Doing this seems to provide a nice speed up for some types of code.

Is it possible to do this on the GP32?

Two possibilities:

1). Run the -fprofile-generate executable directly on the GP32. Will this actually work? notaz stated that the compiled path must match the executable path on the GP32 as this is used to create the associated *.gcda files. I'm not sure if this is possible given the GP32's unique file system structure?

2). Compile the -fprofile-generate executable to run on another machine. ie. If you a profiling a GP32 port which is virtually identical to the GP2X version, run the -fprofile-generate executable on the GP2X and transfer the relevant *.gcda files back to the GP32 compile directory. Is this feasible?


Any other ideas?

 

[slaanesh]

Bouncing this as I'm still interested if anyone knows anything about profiling on the GP32.

Even if it was possible, I would imagine it would need special crt*.o startup/end code to handle writing out the *.gcda files?

I'd really like to get that extra speed increase.

 

[senquack]

Bouncing this as I'm still interested if anyone knows anything about profiling on the GP32.

Even if it was possible, I would imagine it would need special crt*.o startup/end code to handle writing out the *.gcda files?

I'd really like to get that extra speed increase.

I would go the GP2X route and run the profiling on it, then copy the .gcd* files back (can never remember which is which, gcda or gcdo) and compile for the GP32. I know that works.

 

[slaanesh]

I would go the GP2X route and run the profiling on it, then copy the .gcd* files back (can never remember which is which, gcda or gcdo) and compile for the GP32. I know that works.

So, you have successfully done this and know it to work?

Which toolchain did you use? I am using devkitARM r26 for the GP32 but use devkitGP2X for the GP2X.
I would assume I should use devkitARM r26 for the GP2X as well.

BTW: The compiler produces the .gcno files, the executable create the .gcda files when it is run.

EDIT: arm-eabi-gcc doesn't seem to produce .gcno files with -fprofile-generate for some reason? Why?

 

[senquack]

I would go the GP2X route and run the profiling on it, then copy the .gcd* files back (can never remember which is which, gcda or gcdo) and compile for the GP32. I know that works.

So, you have successfully done this and know it to work?

Which toolchain did you use? I am using devkitARM r26 for the GP32 but use devkitGP2X for the GP2X.
I would assume I should use devkitARM r26 for the GP2X as well.

BTW: The compiler produces the .gcno files, the executable create the .gcda files when it is run.

EDIT: arm-eabi-gcc doesn't seem to produce .gcno files with -fprofile-generate for some reason? Why?

I have never compiled a single thing for the GP32, never owned one. But I know someone else here was targeting X86 for the profiling-generate phase, and used those gcda files produced when compiling his arm binary and it worked. He said it did provide some improvement, despite the differing architectures probably normally producing varying statistics. So that led me to the conclusion that you can generate the profiling data on the GP2X, copy it back and compile a GP32 binary.

 

[slaanesh]

I've done a little more experimentation with profiling using Devkit ARM r26. It looks like profiling is supported but no .gcno files are produced by default - however investigation into the .o objects reveal that it does contain the gcov profiling functions.

I've also found that -fgenerate-profile now takes a prefix path.
ie. -fgenerate-profile=<path> where <path> may equal "gp:\gpmm\profiling" for example.

The next problem is that libgcov.a seems to be missing the required functions and there are no gcov type crt*.o files for the GP32.

Full source code is available for gcc & gcov, so I was thinking, it wouldn't be too hard to produce my own?

 

[slaanesh]

I know this is an old thread but I did solve the problems with creating my own libgcov.a for the GP32.
Got the source code but it required quite a few modifications to get it going successfully with the GP32.
Using -fgenerate-profile and then later -fuse-profile generates code which is around 10% faster (and smaller!) than the original code.
A nice gain.

Now just trying to build the same library for Dingoo Native for some nice gains for that platform!

 

[jmetal88]

I hate it, when I come on these boards and read about the stuff you guys figured out, I feel like I know next to nothing about programming. Yet, I'm enrolled in an introductory C++ course at the moment, and I already know practically everything they're teaching in the class. :lol: