[LLVMdev] Updated RFC: ThinLTO Implementation Plan

[Teresa Johnson]

On Wed, Jun 3, 2015 at 1:29 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
> On Mon, Jun 1, 2015 at 6:34 AM, Teresa Johnson <tejohnson at google.com> wrote:
>>
>> On Fri, May 29, 2015 at 6:15 PM, Sean Silva <chisophugis at gmail.com> wrote:
>> >
>> >
>> > On Fri, May 29, 2015 at 8:01 AM, Teresa Johnson <tejohnson at google.com>
>> > wrote:
>> >>
>> >> On Fri, May 29, 2015 at 6:56 AM, Alex Rosenberg <alexr at leftfield.org>
>> >> wrote:
>> >> > My earlier statement about wrapping things in a native object file
>> >> > held
>> >> > in that it is controversial. It appears to be still central to your
>> >> > design.
>> >> >
>> >> > It may help to look at the problem from a different viewpoint: LLVM
>> >> > is
>> >> > not a compiler. It is a framework that can be used to make
>> >> > compiler-like
>> >> > tools.
>> >> >
>> >> > From that view, it no longer makes sense to discuss "the plugin," or
>> >> > gold, or $AR, because there isn't just one of any of those things.
>> >> > ld64
>> >> > isn't the only outlier linker to consider. We have our own linker at
>> >> > Sony,
>> >> > for example. From this perspective, then it makes more sense to
>> >> > consider
>> >> > replacing the binary utilities with ones that support bitcode,
>> >> > because from
>> >> > a user-perspective, all of the linkers already transparently support
>> >> > bitcode
>> >> > directly today, as do ar, nm, etc. This has been necessary for the
>> >> > regular
>> >> > LTO process.
>> >>
>> >> Hi Alex,
>> >>
>> >> It's true that the LLVM versions of these tools support bitcode
>> >> transparently, but not all build systems use LLVM versions of these
>> >> tools, particularly build systems that support a variety of compilers,
>> >> or legacy build systems.
>> >
>> >
>> > If a build system can do
>> > CC=clang
>> > why wouldn't it be able to do
>> > AR=llvm-ar
>> > ?
>>
>> That assumes that the LLVM tools are all deployed in the build system,
>> and adds a requirement for using clang in this mode that wasn't there
>> before when using clang for -O2. We are trying to make the transition
>> from clang -O2 to clang -O2 + ThinLTO as seamless as possible.
>
>
> I'd just like the point out that downthread serious suggestions are being
> fielded to use a nonstandard ELF header or nonstandard bits marking the
> header. This "adds a requirement".
>
> At this point at least 1 (the only?) concrete deployment use case (besides
> yours) that has been brought up in the ThinLTO RFC threads is inconvenienced
> by this design decision. This suggests that native object wrapping doesn't
> offer as much seamlessness as it seems.

One big goal is to make it as painless as possible to transition from
plain -O2 to -O2+thinlto. Users of clang who don't already use LTO
have not had to use/deploy llvm versions of all of these tools
(llvm-nm, llvm-objcopy, llvm-ar, llvm-ranlib, etc), or the plugins for
the native versions of these tools, because they weren't dealing with
bitcode files. That is why we are prioritizing the native wrapped
approach for the initial implementation. For users of the gold linker
(which uses the LTOModule interfaces) this should make it much easier
to enable ThinLTO (from my browsing of ld64 source, it looks like
native-wrapped bitcode should be handled already there too due to the
handling being hidden behind the lto_module API).

Teresa

>
> In general, your proposal contains lots of "we will start out with" type
> constructs regarding the tooling and practical deployment, and it is not
> clear that you have done any feasibility research into whether "we will
> start out with" will turn into "practically speaking, this will only ever be
> implemented in" due to failing to take a sufficiently diverse set of use
> cases into account.
>
> -- Sean Silva
>
>>
>>
>> Teresa
>>
>> >
>> > -- Sean Silva
>> >
>> >>
>> >> And not all build systems have the plugin or
>> >> currently pass it to the native tools that can take a plugin for
>> >> handling bitcode. In those cases the bitcode support is not
>> >> transparently available, and our aim is to reduce the friction as much
>> >> as possible. And not all use LTO currently (I know we don't due to the
>> >> scalability issues we're trying to address with this design), and in
>> >> those cases the migration to bitcode-aware tools and plugins was not
>> >> previously required.
>> >>
>> >> For Sony's linker, are you using the gold plugin or libLTO interfaces?
>> >> If the latter, I suppose some ThinLTO handling would have to be added
>> >> to your linker (e.g. to invoke the LLVM hooks to write the stage-2
>> >> combined function map and either launch the backend processes in
>> >> parallel or write out a make or other build file). The current support
>> >> for reading native object wrapped bitcode is baked into IRObjectFile
>> >> so presumably the Sony linker can handle these native object wrapped
>> >> bitcode files if it uses libLTO. We would similarly embed the handling
>> >> of the function index/summary behind an API that can handle either so
>> >> it is similarly transparent to the linkers. Let me know if there would
>> >> be additional issues that make wrapped bitcode more difficult in your
>> >> case, or how we could make ThinLTO usage simpler for you in general.
>> >>
>> >> >
>> >> > The only tool in the list of tools you mentioned that do not support
>> >> > bitcode directly is objcopy, and that's because nobody has yet
>> >> > written an
>> >> > LLVM-project implementation of it. Personally, I'd much rather you
>> >> > focus on
>> >> > making ThinLTO work by extending bitcode as needed, and we work as a
>> >> > community toward replacing objcopy with an LLVM-native one. It's a
>> >> > big
>> >> > missing piece of the LLVM project today and could be so much better
>> >> > if we
>> >> > could use it to replace Apple's lipo and possibly other extant object
>> >> > file
>> >> > modification tools. (Has anyone surveyed this area?)
>> >> >
>> >> > That older toolchains have tried to slip non-object file data through
>> >> > the binary utilities isn't really proof that this is a good choice.
>> >> > It might
>> >> > simply reflect the realities of those engineering teams. I wasn't at
>> >> > Sun for
>> >> > this, but DTrace needed a linker feature that apparently the Sun
>> >> > linker team
>> >> > was unwilling or unable to provide, so dtrace(1) gained the ability
>> >> > to
>> >> > modify ELF files directly as needed. That doesn't prove that DTrace's
>> >> > USDT
>> >> > feature shouldn't have been implemented in the linker (as ld64 does
>> >> > directly
>> >> > for Apple), does it?
>> >>
>> >> I'd argue that the realities being addressed by using native object
>> >> format in those cases still exist.
>> >>
>> >> >
>> >> > If in the end using native object-wrapped bitcode is the best
>> >> > solution,
>> >> > so be it. However, I think it is largely orthogonal to ThinLTO's
>> >> > needs for
>> >> > transporting symtab data alongside the existing bitcode format.
>> >>
>> >> That's certainly true, ThinLTO can be implemented using either format,
>> >> and bitcode only support can certainly be implemented. It is a matter
>> >> of prioritizing which format to implement first. I had added some
>> >> description to the updated RFC on how the function index/summary can
>> >> be represented, etc in bitcode. Prioritizing the native object format
>> >> doesn't make it easier to implement ThinLTO, but should make it easier
>> >> to deploy.
>> >>
>> >> Thanks!
>> >> Teresa
>> >>
>> >> >
>> >> > Alex
>> >> >



-- 
Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413