Statically linking a small piece of C into every GHC generated binary
metaniklas at gmail.com
Tue Jul 19 21:42:27 CEST 2011
2011/7/19 Johan Tibell <johan.tibell at gmail.com>:
> On Tue, Jul 19, 2011 at 6:02 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
>> I've implemented the primop but run into some difficulty: to use the
>> above fallback I need the code to be statically linked into every
>> binary. I'm not quite sure how to achieve that.
> If dynamic linking doesn't hurt performance (too much). Could I stick
> this piece of C code in ghc-prim? Are we guaranteed to always link
> against ghc-prim?
>> GCC manages by having
>> the above function definition in libc, which is always statically
> I just realized that this isn't true. I wonder if GCC's
> __builtin_popcount suffers a performance degradation when libc is
> dynamically linked.
I assume you meant libgcc and not libc.
I think the linking is a bit of a red herring, ideally they want to
inline it and that requires LTO and static linking and GHC can't do
LTO anyway. There should be little overhead (one extra jump, a cycle
or two) in calling a dynamically linked function compared to a
non-inlined statically linked one.
One small advantage of static linking is that the functions won't be
included if they're not used.
>> I think LLVM uses a small statically linked compiler run-time
>> library for the same purpose.
> However I believe this is the case still. I'll need to doublecheck.
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users