Philip Reames via llvm-dev
2015-Aug-12 21:07 UTC
[llvm-dev] [LLVMdev] RFC: ThinLTO File Format
I went ahead and replied to two of the review threads. I only considered the parts which would be left without the native wrapped bitcode support. Philip On 08/12/2015 01:24 PM, Teresa Johnson wrote:> I can remove the native wrapper portions of the associated patch and > add that later. Most of the support as I mentioned is for the bitcode > handling anyway, but I wanted to include a skeleton of the native > wrapper part. For the RFC, I wanted to show the end goal including how > the native wrapper support would look (it in fact mostly leverages the > same bitcode encoding, so there isn't a lot of difference, and hence > there isn't a whole lot of extra code needed to support that). The > bulk of the RFC deals with the bitcode format, and I would love some > feedback on that. > > Thanks, > Teresa > > On Wed, Aug 12, 2015 at 11:50 AM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > Alex already made what I consider to be the most relevant point. > I would suggest removing the unwanted functionality and asking > again. 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. > > Philip > > > 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 properly. >> >> Thanks, >> Teresa >> >> On Mon, Aug 3, 2015 at 11:59 AM, Teresa Johnson >> <tejohnson at google.com <mailto:tejohnson at google.com>> wrote: >> >> 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 bitcode. >> >> 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. >> >> Thanks, >> Teresa >> >> On Mon, Aug 3, 2015 at 12:26 PM, Alex Rosenberg >> <alexr at leftfield.org <mailto:alexr at leftfield.org>> wrote: >> >> 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 objections. >> >> Alex >> >> On Aug 3, 2015, at 9:19 AM, Teresa Johnson >> <tejohnson at google.com <mailto: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 bitcode. >>> >>> 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: >>> http://reviews.llvm.org/D11722 >>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11722&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=oUy_PB_mSfRgDO7H7bZOR04gv_DMzX5rPO_lv4PHt60&s=WVxrKkHnjKr75fCQ-UkGke8dk6KpZcFCnLWVrJ3G188&e=> >>> >>> 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 >>> >>> >> >> >> -- >> Teresa Johnson | Software Engineer | tejohnson at google.com >> <mailto:tejohnson at google.com> | 408-460-2413 <tel:408-460-2413> >> > > > > > -- > Teresa Johnson | Software Engineer | tejohnson at google.com > <mailto:tejohnson at google.com> | 408-460-2413 <tel:408-460-2413> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150812/7c0d5315/attachment.html>
Teresa Johnson via llvm-dev
2015-Aug-12 21:09 UTC
[llvm-dev] [LLVMdev] RFC: ThinLTO File Format
Saw that, thanks! Responding now. Will update the patch with some changes and the wrapper stuff removed later today or very early tomorrow. Teresa On Wed, Aug 12, 2015 at 2:07 PM, Philip Reames <listmail at philipreames.com> wrote:> I went ahead and replied to two of the review threads. I only considered > the parts which would be left without the native wrapped bitcode support. > > Philip > > > On 08/12/2015 01:24 PM, Teresa Johnson wrote: > > I can remove the native wrapper portions of the associated patch and add > that later. Most of the support as I mentioned is for the bitcode handling > anyway, but I wanted to include a skeleton of the native wrapper part. For > the RFC, I wanted to show the end goal including how the native wrapper > support would look (it in fact mostly leverages the same bitcode encoding, > so there isn't a lot of difference, and hence there isn't a whole lot of > extra code needed to support that). The bulk of the RFC deals with the > bitcode format, and I would love some feedback on that. > > Thanks, > Teresa > > On Wed, Aug 12, 2015 at 11:50 AM, Philip Reames <listmail at philipreames.com > > wrote: > >> Alex already made what I consider to be the most relevant point. I would >> suggest removing the unwanted functionality and asking again. 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. >> >> Philip >> >> >> 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 >> properly. >> >> Thanks, >> Teresa >> >> On Mon, Aug 3, 2015 at 11:59 AM, Teresa Johnson <tejohnson at google.com> >> wrote: >> >>> 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 >>> bitcode. >>> >>> 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. >>> >>> Thanks, >>> Teresa >>> >>> On Mon, Aug 3, 2015 at 12:26 PM, Alex Rosenberg <alexr at leftfield.org> >>> wrote: >>> >>>> 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 >>>> objections. >>>> >>>> Alex >>>> >>>> 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 >>>> bitcode. >>>> >>>> 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: >>>> http://reviews.llvm.org/D11722 >>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11722&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=oUy_PB_mSfRgDO7H7bZOR04gv_DMzX5rPO_lv4PHt60&s=WVxrKkHnjKr75fCQ-UkGke8dk6KpZcFCnLWVrJ3G188&e=> >>>> >>>> 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 >>>> >>>> >>>> >> >> -- >> Teresa Johnson | Software Engineer | tejohnson at google.com | >> 408-460-2413 >> >> >> > > > -- > Teresa Johnson | Software Engineer | tejohnson at google.com | > 408-460-2413 > > >-- Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150812/71f78cc8/attachment.html>
Teresa Johnson via llvm-dev
2015-Aug-13 14:49 UTC
[llvm-dev] [LLVMdev] RFC: ThinLTO File Format
Hi all, I updated the patches to remove the native object wrapper format. As suggested we will work on getting the ThinLTO framework in place using bitcode first, and then work on adding the native object support. As noted in this RFC and in the associated patch D11722, for now I have empty ThinLTO blocks with no records, since I wanted to get feedback on the overall block design first. The RFC discusses this in more detail, but one of the main ideas is to leverage the existing value symbol table block in the module to avoid duplicating function symbol strings, e.g. I also wanted to call out another important design consideration here, since it is buried in the other RFC (ThinLTO File API and Data Structures), and has a big influence on the way I have designed the ThinLTO index and object file data structures. The ThinLTO index is read in compile/link steps when the rest of the Module IR is not, and vice versa. That is why I have separate data structures for reading/holding the ThinLTO index. The ThinLTO index in the module (generated during the initial -c compile step) is needed by other modules during the later parallel backend compile phase, and therefore it is only used in the linker plugin step to create the combined index file. The rest of the Module IR is not read during this step (eventually we may look at adding heavier weight whole program analysis under an option, but by default the Module, Functions, etc are not read or materialized). When the normal Module IR is read during the parallel backend compile step, the ThinLTO information in its own module is not read, as the importing pass will read the combined (global) index file instead. This is because a module is only interested in the ThinLTO index from other modules that it is considering importing from. Right now I have 5 outstanding patches to put in the basic infrastructure/options for reading/writing the ThinLTO function indices: D11721 [ThinLTO] Data structures for holding ThinLTO function index/summary <http://reviews.llvm.org/D11721> D11722 [ThinLTO] Bitcode reading/writing support for ThinLTO function summary/index <http://reviews.llvm.org/D11722> D11723 [ThinLTO] ThinLTO object file interfaces <http://reviews.llvm.org/D11723> D11907 LLVM support for -fthinlto option. <http://reviews.llvm.org/D11907> D11908 Clang support for -fthinlto. <http://reviews.llvm.org/D11908> Once the basic options support, data structs, and bitcode support goes in I can send patches for generating/emitting the function index and the combined function index (off by defaut, guarded by the -fthinlto option), and subsequently send patches for the function importing during the backend compile step. I've tried to break down the above infrastructure into small pieces for review, and plan to implement the rest via incremental patches. Hope this clarifies the approach I'm taking! Looking forward to additional feedback on the approach and the patches. Thanks, Teresa On Wed, Aug 12, 2015 at 2:09 PM, Teresa Johnson <tejohnson at google.com> wrote:> Saw that, thanks! Responding now. Will update the patch with some changes > and the wrapper stuff removed later today or very early tomorrow. > Teresa > > On Wed, Aug 12, 2015 at 2:07 PM, Philip Reames <listmail at philipreames.com> > wrote: > >> I went ahead and replied to two of the review threads. I only considered >> the parts which would be left without the native wrapped bitcode support. >> >> Philip >> >> >> On 08/12/2015 01:24 PM, Teresa Johnson wrote: >> >> I can remove the native wrapper portions of the associated patch and add >> that later. Most of the support as I mentioned is for the bitcode handling >> anyway, but I wanted to include a skeleton of the native wrapper part. For >> the RFC, I wanted to show the end goal including how the native wrapper >> support would look (it in fact mostly leverages the same bitcode encoding, >> so there isn't a lot of difference, and hence there isn't a whole lot of >> extra code needed to support that). The bulk of the RFC deals with the >> bitcode format, and I would love some feedback on that. >> >> Thanks, >> Teresa >> >> On Wed, Aug 12, 2015 at 11:50 AM, Philip Reames < >> listmail at philipreames.com> wrote: >> >>> Alex already made what I consider to be the most relevant point. I >>> would suggest removing the unwanted functionality and asking again. 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. >>> >>> Philip >>> >>> >>> 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 >>> properly. >>> >>> Thanks, >>> Teresa >>> >>> On Mon, Aug 3, 2015 at 11:59 AM, Teresa Johnson <tejohnson at google.com> >>> wrote: >>> >>>> 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 >>>> bitcode. >>>> >>>> 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. >>>> >>>> Thanks, >>>> Teresa >>>> >>>> On Mon, Aug 3, 2015 at 12:26 PM, Alex Rosenberg <alexr at leftfield.org> >>>> wrote: >>>> >>>>> 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 >>>>> objections. >>>>> >>>>> Alex >>>>> >>>>> 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 >>>>> bitcode. >>>>> >>>>> 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: >>>>> http://reviews.llvm.org/D11722 >>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11722&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=oUy_PB_mSfRgDO7H7bZOR04gv_DMzX5rPO_lv4PHt60&s=WVxrKkHnjKr75fCQ-UkGke8dk6KpZcFCnLWVrJ3G188&e=> >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>> >>> -- >>> Teresa Johnson | Software Engineer | tejohnson at google.com | >>> 408-460-2413 >>> >>> >>> >> >> >> -- >> Teresa Johnson | Software Engineer | tejohnson at google.com | >> 408-460-2413 >> >> >> > > > -- > Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413 >-- Teresa Johnson | Software Engineer | tejohnson at google.com | 408-460-2413 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150813/be218a24/attachment.html>