llvm dev - Oct 2014 - [LLVMdev] [lld] lld build needs to have flags that specify what flavor/targets to build ?

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.

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

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.

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>

On Tue, Oct 7, 2014 at 2:31 PM, Rui Ueyama <ruiu at google.com>
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.
>
> 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."
Agreed. I'm fine with having a runtime way to not expose specific
targets in the case you want to ship lld to customers and don't want
to imply you support the other targets.

- Michael Spencer
>
>> 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
>>
>>
>

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.
>
> 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

This it totally "armchair quarterbacking," but I am a little
frustrated that we've come to conflate flavors and targets.

The original intent of flavors was to internally translate each flavor into a
neutral lld-native command line syntax. We now have baked in assumptions of
behavior based on flavor.

If I want to cross-compile from OS X for Windows PECOFF, I don't think it
feels correct to use a LINK.EXE command line flavor from OS X and I'd rather
use an lld-native flavor.

Alex

On 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.
> 
> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Wed, Oct 8, 2014 at 11:45 AM, Alex Rosenberg <alexr at leftfield.org>
wrote:
> This it totally "armchair quarterbacking," but I am a little
frustrated
> that we've come to conflate flavors and targets.
>
> The original intent of flavors was to internally translate each flavor
> into a neutral lld-native command line syntax. We now have baked in
> assumptions of behavior based on flavor.
>
> If I want to cross-compile from OS X for Windows PECOFF, I don't think
it
> feels correct to use a LINK.EXE command line flavor from OS X and I'd
> rather use an lld-native flavor.
>
What do we get by making each flavor's driver to a translator to the
"universal" lld driver? The merit is not obvious to me, while I'm
sure we
would have to invent a new syntax for the unviersal driver and maintain the
extra layer.

Another question is that if we make such universal driver, it will support
all the options of all flavors in some way, but what combination of the
options are allowed? Some option mapping is obvious; for example --verbose
in ld and /verbose in link.exe should be mapped to the same option.
However, --entry and /entry should not be mapped to the same option,
because their semantics are slightly different. If - lazy is given, should
it be interpreted as /delayload when linking PECOFF?

We may be able to answer all the questions. But it's not clear to me what
we get from all that efforts.

Alex
>
> On 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.
> >
> > 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
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141008/2bf2c9e2/attachment.html>