Does anyone have any experience of what can be profiled in the profiled guided optimisations?
One of the problems with some of the string routines is that you can write pretty neat fast routines that work well for long strings - but most of the calls actually pass short strings and the overhead of the fast routine means that for most cases you are slower than you would have been with a simple routine.
If Profile Guiding could spot that a particular callsite to say strlen() was often associated with strings of at least 'n' characters we could call a different implementation.
Dave
On 12/16/2010 6:25 AM, David Gilbert wrote:
If Profile Guiding could spot that a particular callsite to say strlen() was often associated with strings of at least 'n' characters we could call a different implementation.
I don't believe this is possible current profile-guided optimization, but certainly it could be done.
Ideally, we would avoid hard-coding something about strlen into the compiler.
Instead, something like this:
* Have the compiler expose an API for recording information about the value of arguments to a function when profiling. For integer arguments, this might be the minimum, maximum, and average. For pointers, NULL vs. non-NULL. Etc.
* Plumb this through the profiler and analysis tools.
* Provide a plug-in that allows the user to instrument particular functions (e.g., strlen) by providing profiling rules:
- instrument length argument to strlen at all callsites - if length < 8: replace with call to strlen_short
This is obviously more work than a special-purpose hack for strlen, but this is the sort of thing where exposing the rules outside of the compiler proper would be very helpful because the right answers are going to change depending on the application and on the core.
On 16/12/10 15:06, Mark Mitchell wrote:
- Have the compiler expose an API for recording information about the
value of arguments to a function when profiling. For integer arguments, this might be the minimum, maximum, and average. For pointers, NULL vs. non-NULL. Etc.
Presumably recording the return value of functions would also be handy, especially in this case?
- Provide a plug-in that allows the user to instrument particular
functions (e.g., strlen) by providing profiling rules:
This is cool, but most users want it to Just Work (tm). Is a plugin a suitable way to implement an on-by-default feature?
Andrew
On 12/17/2010 2:51 AM, Andrew Stubbs wrote:
- Have the compiler expose an API for recording information about the
value of arguments to a function when profiling. For integer arguments, this might be the minimum, maximum, and average. For pointers, NULL vs. non-NULL. Etc.
Presumably recording the return value of functions would also be handy, especially in this case?
Indeed.
- Provide a plug-in that allows the user to instrument particular
functions (e.g., strlen) by providing profiling rules:
This is cool, but most users want it to Just Work (tm). Is a plugin a suitable way to implement an on-by-default feature?
I think so. The plug-in could always ship with the compiler, just as various Eclips plug-ins ship with Eclipse, or as various kernel modules ship with the kernel. The benefit of a plug-in interface is not just third-party delivery, but also the ability for users to modify and configure behavior.
We've traditionally hard-coded things into the compiler to optimize the behavior of built-in functions, but that's something that should (ideally) be under the control of users. For example, a library developer might very well like to ship some Python code that told the compiler that calling f(g(x)) is equivalent to calling h(x), or that if n < 3, you should translate f(n) into g(1); ...; g(n).
linaro-toolchain@lists.linaro.org
-
Andrew Stubbs -
David Gilbert -
Mark Mitchell