[LLVMdev] [lld] lld build needs to have flags that specify what flavor/targets to build ?

Rui Ueyama ruiu at google.com
Tue Oct 7 14:31:07 PDT 2014

On Tue, Oct 7, 2014 at 2:22 PM, Shankar Easwaran <shankare at codeaurora.org>

> On 10/7/2014 4:10 PM, Nick Kledzik wrote:
>> Shankar,
>> Can you give provide a scenario where you want this?  I’m not sure what
>> you want here.
> a) LLVM could be built  just for one target(LLVM_TARGETS_TO_BUILD)
> b) With LTO this case might happen more often, where an user would have
> compiled LLVM just for one architecture and lld would support other
> architectures that LLVM would not support.
> c) Printing all the targets/flavors that the linker currently supports.

What's the motivation to build a LLD only for some specific target? Size?

LLD is not a large executable. When compiled with Release, it's a few
megabyte binary. If you kill architectures that you don't need, you won't
save that much.

On the other hand, making something configurable always comes with cost.
It's not hard to imagine that we would get a bug reports that "feature X
didn't work if we build LLD only for target Y."

On Oct 7, 2014, at 2:03 PM, Shankar Easwaran <shankare at codeaurora.org>
> wrote:
>> Hi,
>>> I think lld needs to have an infrastructure as part of the build process
>>> to build specific flavors and specific targets.
>> This sounds like you want config-time choices (e.g. build a linker to
>> only support ELF/x86 such as for a JIT).
> Yes.
>  For this I was thinking that the Registry expand to consider flavors and
>>> targets that are part of the build process.
>>> So each flavor/target would register and the Driver would walk through
>>> the list of handlers to check if there is a handler defined for that
>>> flavor/target.
>> This sounds like you want everything decided at runtime (e.g. all flavors
>> registers all readers).
> Yes, right.
> Shankar Easwaran
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by the Linux Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141007/a96209b7/attachment.html>

More information about the llvm-dev mailing list