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

Rui Ueyama ruiu at google.com
Tue Oct 7 16:41:52 PDT 2014


On Tue, Oct 7, 2014 at 4:26 PM, Shankar Easwaran <shankare at codeaurora.org>
wrote:

> On 10/7/2014 4:31 PM, Rui Ueyama wrote:
>
>> On Tue, Oct 7, 2014 at 2:22 PM, Shankar Easwaran <shankare at codeaurora.org
>> >
>> wrote:
>>
>>  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.
>>
> a) The motivation is just that LLVM enables specific targets to be enabled
> at compile time.
> b) Most users wont build COFF/MachO on Linux, so I dont think having that
> functionality makes sense, right ?
> c) Most customers will want a linker for the architecture that they want
> to support, so we need to think of a solution to not enable other targets.


As Michael implied, you can kill a few lines from the driver dispatcher to
disable drivers that you don't want to expose to your customer. That
approach will save everybody's time including you because of reduction of
complexity (I don't think we want to test 2^n combinations where n is the
number of architectures). The executable will include some dead code, but
it won't be that much, so it seems like a good tradeoff to me.


>> 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
>>>
>>>
>>>
>>>
>
> --
> 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/99cf09fe/attachment.html>


More information about the llvm-dev mailing list