This is the mail archive of the 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]
Other format: [Raw text]

Re: Reduce fpic related slowdowns

Robert Wohlrab <> writes:

> I am currently trying to move some parts of a bigger program to an external 
> library that can be used to process a big amount of data. This is done because 
> different frontends should be able to use the library. It only has some 
> functions to set extra data, but most of it is done by invoking a single 
> function which reads a buffer and starts some functions as reaction. So it 
> just interprets the data. The first try to compile it using -fPIC results in a 
> massive slowdown (~20%), but this could be reduced by compiling with -
> fvisibility=hidden. The compiler now reduced the start block in each function 
> slightly and we only had a slowdown of ~5%. Next idea was to mark all 
> functions which are only used by the interpreter function as internal. We 
> don't pass that functions to the outside and they shouldn't be callable - my 
> idea was that is should now as fast as it was before as the init block in 
> internal functions could be dropped and replaced by an easier init block which 
> is similar to the non-PIC block. This doesn't happen here and the results are 
> the same as with using -fvisibility=hidden.
> Is this not possible or just not implemented by gcc at the moment? Are there 
> maybe other ways to reduce the speed penalty due to -fPIC without removing the 
> internal functions.
> Target architectures are currently i386 and amd64 - so disabling PIC isn't 
> possible on amd64.

There is always a penalty for using -fPIC, because the code must be
position independent.  The usual penalty I've measured is more like 2
to 3%.  A 5% penalty seems a trifle high, but certainly possible if
your code uses a lot of global variables.

It sounds like you have specific examples where the code is worse.  If
you post them we may be able to tell you whether it is possible to do


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