similar to: [LLVMdev] RFC: ThinLTO File Format

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

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

On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi, > > As part of PR27551 I want to add a string table to the bitcode format to > allow global value and comdat names to be shared with the proposed symbol > table (and, as side effects, allow comdat

Hi, As part of PR27551 I want to add a string table to the bitcode format to allow global value and comdat names to be shared with the proposed symbol table (and, as side effects, allow comdat names to be shared with value names, make bitcode files more compressible and make bitcode easier to parse). The format of the string table would be a top-level block containing a blob containing

On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > Hi, > > As part of PR27551 I want to add a string table to the bitcode format to > allow global value and comdat names to be shared with the proposed symbol > table (and, as side effects, allow comdat

On Tue, Apr 4, 2017 at 1:25 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Apr 4, 2017, at 12:12 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >> >> Hi,

Hi Jan, > I've been looking into how to make llvm bitcode files smaller. There is one > simple change that appears to shrink linked bitcode files by about 15%. See > this spreadsheet for some rough data: > > https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E the improvement is wonderful! ... > In any case, the patch is attached if

Hi all, I've been looking into how to make llvm bitcode files smaller. There is one simple change that appears to shrink linked bitcode files by about 15%. See this spreadsheet for some rough data: https://docs.google.com/spreadsheet/ccc?key=0AjRrJHQc4_bddEtJdjdIek5fMDdIdFFIZldZXzdWa0E The change is in how operand ids are encoded in bitcode files. Rather than use an "absolute

Hi, I currently write a tool to parse the LLVM bytecode file (.bc file). So I have some very basic questions: - First, about the Abbreviation ID ( "0"=END_BLOCK, "1"=ENTER_SUBBLOCK...): how to read these ID from the file stream ? I mean, I don't know, how many bit length they are. It doesn't exist on the document. - Second, how is the order to read the bytecode ? For

Thanks! Question about the final link step: Do I provide all the object files to the link step, i.e. something like: clang++ -o thinlto main-native.o lib/lib-native.o src/lib-native.o Do I need to provide --start-lib markers on that final link step as well? Tanoy On Tue, Jun 18, 2019 at 10:37 AM Teresa Johnson <tejohnson at google.com> wrote: > Hi Tanoy, > > You can't use

Hi Mehdi, Awesome! It’s a very clear design. The only question left is which pipeline to choose for unified compile-phase optimization pipeline. - ThinLTO compile-phase pipeline? It might very negatively affect compile-time and the memory footprint for FullLTO link-phase. That was the reason why so many optimization were moved from the link-phase to the parallel compile-phase for FullLTO

Le mar. 10 avr. 2018 à 23:18, <katya.romanova at sony.com> a écrit : > Hi Mehdi, > > > > Awesome! It’s a very clear design. The only question left is which > pipeline to choose for unified compile-phase optimization pipeline. > > - ThinLTO compile-phase pipeline? It might very negatively affect > compile-time and the memory footprint for FullLTO link-phase.

Hi, It is non trivial to recompute summaries (which is why we have summaries in the bitcode in the first place by the way), because bitcode is expensive to load. I think shipping two different variant of the bitcode, one with and one without summaries isn't providing much benefit while complicating the flow. We could achieve what you're looking for by revisiting the flow a little. I

From: Mehdi AMINI <joker.eph at gmail.com> Sent: Tuesday, April 10, 2018 11:53 PM To: Romanova, Katya <katya.romanova at sony.com> Cc: David Blaikie <dblaikie at gmail.com>; Teresa Johnson <tejohnson at google.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization

On Tue, Apr 10, 2018 at 11:52 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > Le mar. 10 avr. 2018 à 23:18, <katya.romanova at sony.com> a écrit : > >> Hi Mehdi, >> >> >> >> Awesome! It’s a very clear design. The only question left is which >> pipeline to choose for unified compile-phase optimization pipeline. >> >> -

Hi David, Thank you so much for your reply! >> You're dealing with a situation where you are shipped BC files offline and then do one, or multiple builds with these BC files? Yes, that’s exactly the case. >> If the scenario was more like a naive build: Multiple BC files generated on a single (multi-core/threaded) machine (but some Thin, some >> Full) & then fed to the

I've included below an RFC for implementing ThinLTO in LLVM, looking forward to feedback and questions. Thanks! Teresa RFC to discuss plans for implementing ThinLTO upstream. Background can be found in slides from EuroLLVM 2015: https://drive.google.com/open?id=0B036uwnWM6RWWER1ZEl5SUNENjQ&authuser=0) As described in the talk, we have a prototype implementation, and would like to

I met with the Propeller team today (we work for the same company but it was my first time meeting two members on the team:) ). One thing I have been reassured: * There is no general disassembly work. General disassembly work would assuredly frighten off developers. (Inherently unreliable, memory usage heavy and difficult to deal with CFI, debug information, etc) Minimal amount of plumbing work

I am trying to work through the usage of thinlto for distributed builds. Here is the simple thinlto usage, just add -flto=thin everywhere, easy: clang++ -flto=thin -O3 -c -o CreateWay_.o -DSPEC_CPU -DNDEBUG -DSPEC_CPU_LITTLE_ENDIAN -Wno-dangling-else CreateWay_.cpp clang++ -flto=thin -O3 -c -o Places_.o -DSPEC_CPU -DNDEBUG -DSPEC_CPU_LITTLE_ENDIAN

I'm trying to run distributed ThinLTO without thin archives. When I do, I get an error in the optimizer when clang tries to open a nonexistent file: clang++ -flto=thin -Xclang -fno-lto-unit -O3 -c main.cpp -o main.o clang++ -flto=thin -Xclang -fno-lto-unit -O3 -c lib/lib.cpp -o lib/lib.o clang++ -flto=thin -Xclang -fno-lto-unit -O3 -c src/lib.cpp -o src/lib.o llvm-ar -format gnu qcs lib.a