<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 7, 2014 at 4:26 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.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="">On 10/7/2014 4:31 PM, Rui Ueyama wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Oct 7, 2014 at 2:22 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/7/2014 4:10 PM, Nick Kledzik wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Shankar,<br>
<br>
Can you give provide a scenario where you want this?  I’m not sure what<br>
you want here.<br>
<br>
</blockquote>
a) LLVM could be built  just for one target(LLVM_TARGETS_TO_BUILD)<br>
b) With LTO this case might happen more often, where an user would have<br>
compiled LLVM just for one architecture and lld would support other<br>
architectures that LLVM would not support.<br>
c) Printing all the targets/flavors that the linker currently supports.<br>
</blockquote>
<br>
What's the motivation to build a LLD only for some specific target? Size?<br>
<br>
LLD is not a large executable. When compiled with Release, it's a few<br>
megabyte binary. If you kill architectures that you don't need, you won't<br>
save that much.<br>
</blockquote></span>
a) The motivation is just that LLVM enables specific targets to be enabled at compile time.<br>
b) Most users wont build COFF/MachO on Linux, so I dont think having that functionality makes sense, right ?<br>
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.</blockquote><div><br></div><div>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.</div><div><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">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On the other hand, making something configurable always comes with cost.<br>
It's not hard to imagine that we would get a bug reports that "feature X<br>
didn't work if we build LLD only for target Y."<br>
<br>
On Oct 7, 2014, at 2:03 PM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think lld needs to have an infrastructure as part of the build process<br>
to build specific flavors and specific targets.<br>
<br>
</blockquote>
This sounds like you want config-time choices (e.g. build a linker to<br>
only support ELF/x86 such as for a JIT).<br>
<br>
</blockquote>
Yes.<br>
<br>
  For this I was thinking that the Registry expand to consider flavors and<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
targets that are part of the build process.<br>
<br>
So each flavor/target would register and the Driver would walk through<br>
the list of handlers to check if there is a handler defined for that<br>
flavor/target.<br>
<br>
</blockquote>
This sounds like you want everything decided at runtime (e.g. all flavors<br>
registers all readers).<br>
<br>
</blockquote>
Yes, right.<br>
<br>
<br>
Shankar Easwaran<br>
<br>
--<br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted<br>
by the Linux Foundation<br>
<br>
<br>
<br>
</blockquote></blockquote>
<br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
<br>
</div></div></blockquote></div><br></div></div>