On 05/06/2015 09:24 AM, Alexander Monakov wrote:
On Mon, 4 May 2015, Jeff Law wrote:
On 05/04/2015 11:39 AM, Jakub Jelinek wrote:
On Mon, May 04, 2015 at 11:34:05AM -0600, Jeff Law wrote:
On 05/04/2015 10:37 AM, Alexander Monakov wrote:
This patch introduces option -fno-plt that allows to expand calls that
would
go via PLT to load the address of the function immediately at call site
(which
introduces a GOT load). Cover letter explains the motivation for this
patch.
New option documentation for invoke.texi is missing from the patch; if
this is
accepted I'll be happy to send a v2 with documentation added.
* calls.c (prepare_call_address): Transform PLT call to GOT lookup and
indirect call by forcing address into a pseudo with -fno-plt.
* common.opt (flag_plt): New option.
OK once you cobble together the invoke.texi changes.
Isn't what Michael/Alan suggested better? I mean as/ld/compiler changes to
inline the plt slot's first part, then lazy binding will work fine.
I must have missed Alan/Michael's message.
ISTM the win here is that by going through the GOT, you can CSE the GOT
reference and possibly get some more register allocation freedom. Is that
still the case with Alan/Michael's approach?
If the same PLT stubs as today are to be used, it constrains the compiler on
32-bit x86 and possibly other arches where PLT stubs need GOT pointer in a
specific register. It's possible to imagine more complex PLT stubs that
obtain GOT pointer on their own, but in that case you can't let optimizations
such as loop invariant motion move the GOT load away from the call in a
fashion that could result in PLT stub pointer be reused many times.
Going ahead with this patch now allows anyone to play with no-PLT codegen on
any architecture. As you can see from this series, on x86 it uncovered several
codegen blunders (and fixing those should improve normal codegen as well -- so
everybody wins).
Below is my proposed patch for invoke.texi. Still OK to check in?
* doc/invoke.texi (Code Generation Options): Add -fno-plt.
([-fno-plt]): Document.
We're not changing the defaults, so I think this is fine. Whether or
not it proves useful is still to be determined.
jeff
