yes -- it is good to turn this on by default in LTO mode without requiring user to specify the option.
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.
