(original) (raw)
On Tue, Oct 7, 2014 at 4:26 PM, Shankar Easwaran <shankare@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@codeaurora.org>a) The motivation is just that LLVM enables specific targets to be enabled at compile time.
wrote:
On 10/7/2014 4:10 PM, Nick Kledzik wrote:
Shankar,a) LLVM could be built just for one target(LLVM\_TARGETS\_TO\_BUILD)
Can you give provide a scenario where you want this? I’m not sure what
you want here.
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.
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@codeaurora.org>
wrote:
Hi,Yes.
I think lld needs to have an infrastructure as part of the build processThis sounds like you want config-time choices (e.g. build a linker to
to build specific flavors and specific targets.
only support ELF/x86 such as for a JIT).
For this I was thinking that the Registry expand to consider flavors and
Yes, right.targets that are part of the build process.This sounds like you want everything decided at runtime (e.g. all flavors
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.
registers all readers).
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