This is the mail archive of the
mailing list for the GCC project.
Re: basic-block and profile-based optimizing (was Re: New attribute"infrequent"?)
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: basic-block and profile-based optimizing (was Re: New attribute"infrequent"?)
- From: Andreas Jaeger <aj at suse dot de>
- Date: Fri, 31 Aug 2001 21:55:54 +0200
- Cc: Scott A Crosby <crosby at qwes dot math dot cmu dot edu>, Jan Hubicka <jh at suse dot cz>, gcc at gcc dot gnu dot org, pfk at fuchs dot offl dot uni-jena dot de
- References: <200108311705.NAA25786@makai.watson.ibm.com>
David Edelsohn <firstname.lastname@example.org> writes:
>>>>>> Andreas Jaeger writes:
> Andreas> But how does an application get the
> Andreas> information that a function of the library is infrequently used?
> Andreas> I don't see at the moment a way to get this information from one
> Andreas> object, the library, to a totally different one, the application -
> Andreas> especially when both are compiled and profiled by different developers
> Andreas> on different systems.
> I do not understand your concern. Why does the information need
> to be communicated between objects?
There're two issues here:
- profiling a library and using profile driven optimizations to
optimize the library for common use
- building an application that knows a bit more about the library and
can optimize stuff.
I do see now less problems with the first point, it should be possible
to build an optimized library.
> I am suggesting compiling the library with profiling, not the
> application. One runs a representative *real* application linked against
> the profiled library. One uses profile-directed feedback to optimize the
> library. The library (presumably shared library) is optimized exactly
> once and included in whatever distribution and binary RPMs.
> Will the optimization be best for all applications? No. But is
> the current, non-profile directed optimization best for all applications?
> Again, no. Will some of the profile-directed optimizations be generic and
> useful for most, normal applications? Yes.
> Let me reiterate that I am considering the case of system shared
> libraries, not object archives local to an application.
And I considered an application that uses this library.
If we know more than just the plain prototypes about the functions, we
can do more optimizations in the application:
- if we know that a library function is pure or constant, this allows
certain optimizations in the application. For local functions we
might deduce this, but we won't for library functions called by an
- The same applies for exceptional, error functions in the library
that are called by an application.
Sorry for the misunderstandings, I hope having made the points clear
this time and not increased the confusion even more.
SuSE Labs email@example.com