<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 12, 2016 at 6:10 PM, David Farler via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Apr 12, 2016, at 6:08 PM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br>
><br>
><br>
>> On Apr 12, 2016, at 5:59 PM, David Farler via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Hello llvm-dev,<br>
>><br>
>> 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.<br>
><br>
> 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?<br>
><br>
> Having things in a header is not nice for compile-time, we should try to move things out-of-headers instead of adding more.<br>
><br>
> --<br>
> Mehdi<br>
><br>
><br>
><br>
>><br>
>> I see that this method was pulled out of line for <a href="https://llvm.org/bugs/show_bug.cgi?id=3758" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=3758</a> 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.<br>
>><br>
>> David<br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
<br>
</span>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.<br></blockquote><div><br>So the solution might be to compile LLVM's libSupport for all the target architectures you're interested in.<br><br>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.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
David<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>