[LLVMdev] RFC: ThinLTO Impementation Plan
Daniel Berlin
dberlin at dberlin.org
Thu May 14 13:39:44 PDT 2015
On Thu, May 14, 2015 at 12:53 PM, Eric Christopher <echristo at gmail.com> wrote:
>
>
> On Thu, May 14, 2015 at 11:34 AM Daniel Berlin <dberlin at dberlin.org> wrote:
>>
>> On Thu, May 14, 2015 at 11:14 AM, Eric Christopher <echristo at gmail.com>
>> wrote:
>> > I'm not sure this is a particularly great assumption to make.
>>
>> Which part?
>
>
> The binutils part :)
I took it as the more general: "we want to simply work with native
toolchains", not as something specific to binutils.
>
>>
>>
>> > We have to
>> > support a lot of different build systems and tools and concentrating on
>> > something that just binutils uses isn't particularly friendly here.
>> I think you may have misunderstood
>> His point was exactly that they want to be transparent to *all of* these
>> tools.
>> You are saying "we should be friendly to everyone". He is saying the same
>> thing.
>> We should be friendly to everyone. The friendly way to do this is to
>> not require all of these tools build plugins to handle bitcode.
>>
>> Hence, elf-wrapped bitcode.
>
>
> Oh, I understood. I just don't know that I agree.
Fair enough. I just wanted to make sure there wasn't a misunderstanding here :)
> To do anything with the
> tools will require some knowledge of bitcode anyhow or need the plugin.
This is certainly true, but that's part of the point - the ability to
pass through native tools without them breaking, or worrying about
the bitcode there.
> I'm
> saying that as a baseline start we should look at how to do this using the
> tools we've got rather than wrapping things for no real gain.
The gain is precisely: "People on different platforms do not have to
use all-llvm tools to have this build mode work".
>
> I've talked to Teresa a bit offline and we're going to talk more later (and
> discuss on the list), but there are some discussions about how to make this
> work either with just bitcode/llvm tools and so not requiring integration on
> all platforms. The latter is what I consider as particularly friendly :)
Sure, if you have a way to make this work that doesn't require
everyone in the world replace ar with llvm-ar and ld with llvm-ld,
sounds awesome :)
(I actually have no real dog in this fight, just trying to make sure
everyone is on the same page ;P)
More information about the llvm-dev
mailing list