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.
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.
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.
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.
>
>
>>
>> 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 3758 – SmallVector::grow/swap should be shared for POD T's 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@lists.llvm.org
>> llvm-dev Info Page
>
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.