On Fri, May 1, 2015 at 9:26 AM, Xinliang David Li <davi...@google.com> wrote: > yes -- it is good to turn this on by default in LTO mode without > requiring user to specify the option.
Yes, with LTO, we would exactly know what the "truly extern" functions are and PLT stubs can be eliminated for all extern functions when early binding is specified. With lazy binding, we can eliminate the PLT stubs selectively for the hot extern functions. Thanks Sri > > David > > On Fri, May 1, 2015 at 9:23 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >> On Fri, May 1, 2015 at 9:19 AM, Xinliang David Li <davi...@google.com> wrote: >>> On Fri, May 1, 2015 at 8:01 AM, Andi Kleen <a...@firstfloor.org> wrote: >>>> Sriraman Tallam <tmsri...@google.com> writes: >>>>> >>>>> This comes with caveats. This cannot be generally done for all >>>>> functions marked extern as it is impossible for the compiler to say if >>>>> a function is "truly extern" (defined in a shared library). If a >>>>> function is not truly extern(ends up defined in the final executable), >>>>> then calling it indirectly is a performance penalty as it could have >>>>> been a direct call. Further, the newly created GOT entries are fixed >>>>> up at start-up and do not get lazily bound. >>>> >>>> This means you need to make it depend on -fno-semantic-interposition ? >>>> >>>>> Given this, I propose adding a new option called >>>>> -fno-plt=<function-name> to the compiler. This tells the compiler >>>>> that we know that the function is truly extern and we want the >>>>> indirect call only for these call-sites. I have attached a patch that >>>>> adds -fno-plt= to GCC. Any number of "-fno-plt=" can be specified and >>>>> all call-sites corresponding to these named functions will be done >>>>> indirectly using the mechanism described above without the use of a >>>>> PLT stub. >>>> >>>> The argument seems awkward. The command line may get very long. >>>> Better an attribute? >>> >>> They are complementary. Perhaps another option like linker's >>> --dynamic-list=<> that can take a file specifying the list of symbols. >>> >>>> >>>> Longer term it would be probably better to support it properly >>>> in the linker. >>>> >>> >>> Linker solution has its own downside -- it require reserving more >>> space conservatively for many callsites which end up being direct >>> calls. >>> >> >> Can we do it automatically for LTO? >> >> >> -- >> H.J.
