This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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

Re: basic-block and profile-based optimizing (was Re: New attribute"infrequent"?)


David Edelsohn <dje@watson.ibm.com> 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
  application.
- 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.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj


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