[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