[llvm-dev] Inline SmallVectorBase::grow_pod?

[David Blaikie via llvm-dev]

On Tue, Apr 12, 2016 at 6:10 PM, David Farler via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> > On Apr 12, 2016, at 6:08 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> >
> >
> >> On Apr 12, 2016, at 5:59 PM, David Farler via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>
> >> Hello llvm-dev,
> >>
> >> I'm working on some out-of-process reflection support for Swift and I'd
> like to switch over some of my memory management to context-based with a
> bump-pointer allocator. I hit a linker error that `grow_pod` was missing.
> Eventually, some of this code will get linked into the Swift runtime and we
> are trying to avoid directly linking LLVM into the runtime to keep the size
> down, so I can't link in Support.
> >
> > If code size is your motivation, any dead-stripping by the linker should
> remove all the code from libLLVMSupport that you are not actually using.
> It's not clear how moving every pieces you need to a header would help
> here. Have you some elements that shows how much of Support can't be
> dead-stripped from your binary?
> >
> > Having things in a header is not nice for compile-time, we should try to
> move things out-of-headers instead of adding more.
> >
> > --
> > Mehdi
> >
> >
> >
> >>
> >> I see that this method was pulled out of line for
> https://llvm.org/bugs/show_bug.cgi?id=3758 back in 2009. Is there a
> chance we can consider pulling it back into a header? It's kind of a shame
> to have to have to link Support just to use BumpPointerAllocator.
> >>
> >> David
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> There is also the fact that we simply don't compile LLVM for all target
> architectures in Swift (because we don't link it into the standard library
> or runtime); we only build it for the host.
>

So the solution might be to compile LLVM's libSupport for all the target
architectures you're interested in.

It seems like not such a great idea to pull out pieces of LLVM's APIs into
headers so they can be used header-only. That doesn't seem like a goal we
would want to support as it would contort the APIs (as mentioned, it's not
the best thing for the code, potentially (hence why it was pulled out)) &
it'd go relatively untested in LLVM so would be likely to be regressed
pretty easily, I'd imagine.

- Dave


>
> David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160413/8bb07f53/attachment.html>