[llvm-dev] [LLVMdev] RFC: ThinLTO File Format
Xinliang David Li via llvm-dev
llvm-dev at lists.llvm.org
Wed Aug 12 12:18:58 PDT 2015
On Wed, Aug 12, 2015 at 11:50 AM, Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Alex already made what I consider to be the most relevant point. I would
> suggest removing the unwanted functionality and asking again.
I find your definition of 'unwanted' too narrow -- there are certainly
users who may want this. It would be a more productive discussion if the
comments can be made on the details of the RFCs themselves.
>From my perspective, native wrapped bitcode is only interesting (and thus
> worth reviewing and/or talking about) once the native bitcode version is in
> tree and functional. Frankly, I consider the native wrapped bitcode to be
> an entirely orthogonal proposal that shouldn't be tied to ThinLTO at all.
> Fair warning, I'm not going to be particularly involved either way. This
> is far enough from my own immediate interests that I can't spare the
> cycles. I would suggest that you collaborate closely with the Sony and
> Apple folks who are already *using* LTO to find a proposal they're happy
> with. Until you do that, you are unlikely to make much progress.
> On 08/12/2015 09:13 AM, Teresa Johnson wrote:
> Ping. Explicitly adding a few more people who commented on the earlier
> (high-level) ThinLTO RFC. I removed the body of the RFC here since the
> original was large and had trouble getting through the mailer. I also
> updated the patch mentioned below so that it was emailed to llvm-commits
> On Mon, Aug 3, 2015 at 11:59 AM, Teresa Johnson <tejohnson at google.com>
>> Hi Alex,
>> After outlining some of the rationale for using native-wrapped, there
>> were a couple of responses that indicated native-wrapped support was
>> reasonable, but they preferred to see bitcode-only first (Phillip and
>> Rafael). This is essentially what this proposal and the patches do - I've
>> implemented some of the basic support for looking for and parsing the
>> native-wrapped sections, but the bitcode-only reading/writing support is
>> more complete.
>> In fact, as described in this RFC, I designed the native-wrapped format
>> to utilize the same bitcode encoding for most of the ThinLTO information,
>> so it uses most of the same underlying bitcode interfaces anyway. The
>> additional support required for native-wrapped is not tremendous, and is
>> similar to existing support in the LLVM tree for reading native-wrapped
>> We believe that there will be clang/llvm users who will find
>> native-wrapped ThinLTO easier to use for the same reasons (e.g.
>> compatibility with existing native toolchains), so I don't expect this to
>> be Google specific.
>> On Mon, Aug 3, 2015 at 12:26 PM, Alex Rosenberg <alexr at leftfield.org>
>>> I think I've read all the feedback posted regarding your May proposal. I
>>> have yet to see a single response that wants native object wrapped bitcode.
>>> If the only use for native object wrapped bitcode is for your project at
>>> Google, then it probably shouldn't go into the tree against all of these
>>> On Aug 3, 2015, at 9:19 AM, Teresa Johnson <tejohnson at google.com> wrote:
>>> As discussed in the high-level ThinLTO RFC (
>>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-May/086211.html), we
>>> would like to add support for native object wrapped bitcode and ThinLTO
>>> information. Based on comments on the mailing list, I am adding support for
>>> ThinLTO in both normal bitcode files, as well as native-object wrapped
>>> The following RFC describes the planned file format of ThinLTO
>>> information both in the bitcode-only and native object wrapped cases. It
>>> doesn't yet define the exact record format, as I would like feedback on the
>>> overall block design first.
>>> I've also implemented the support for reading and writing the bitcode
>>> blocks in the following patch:
>>> The ThinLTO data structures and the file APIs are described in a
>>> separate RFC I will be sending simultaneously, with pointers to the patches
>>> implementing them.
>>> Looking forward to your feedback. Thanks!
> Teresa Johnson | Software Engineer | tejohnson at google.com |
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev