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.
