similar to: RFC: Moving the module summary into the irsymtab

On Mon, May 1, 2017 at 11:06 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > 2017-04-25 12:11 GMT-07:00 Peter Collingbourne <peter at pcc.me.uk>: > >> Hi all, >> >> I've been making a number of changes to the summary representation >> recently, and I wanted to lay out some of my plans so that folks are aware >> of my ultimate

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

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

I think for ld64, you can mix thinLTO and fullLTO files and ld64 is going to compile them separately and combine the result. (Mehdi can confirm). I think this is aligned with the fact that whether to use full or thin LTO is decided during clang invocation, not linker invocation. I am not against any of the model, but I think we need to do some research before making the effort to switch the model.

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 Katya, [+Teresa since this is about ThinLTO & she's the owner there] I'm not sure how other folks feel, but terminologically I'm not sure I think of these as different formats (for example you mention the idea of stripping the summaries from ThinLTO BC files to then feed them in as FullLTO files - I would imagine it'd be reasonable to modify/fix/improve the linker

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. >> >> -

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

Hello, I am exploring the possibility of unifying the BC file generation phase for ThinLTO and FullLTO. Our third party library providers prefer to give us only one version of the BC archives, rather than test and ship both Thin and Full LTO BC archives. We want to find a way to allow our users to pick either Thin or Full LTO, while having only one "unified" version of the BC archive.

Hi Teresa, Thank you so much for your reply! I am on vacation until the end of this week and on EuroLLVM next week, so I have to apologize in advance that my replies are delayed. >>Right - see my reply on this from last night, at the very least the ThinLTO importing thresholds will need retuning if we will >>perform optimizations like unrolling/vectorization/etc that tend to

Le mer. 11 avr. 2018 à 11:20, <katya.romanova at sony.com> a écrit : > > > > > *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

See attached some quick slides (backup from the dev meeting talk) about the pass pipeline. -- Mehdi Le mer. 11 avr. 2018 à 12:18, Mehdi AMINI <joker.eph at gmail.com> a écrit : > > > Le mer. 11 avr. 2018 à 11:20, <katya.romanova at sony.com> a écrit : > >> >> >> >> >> *From:* Mehdi AMINI <joker.eph at gmail.com> >> *Sent:*

Adding Peter to comment on the linker resolution issue. >From adding save-temps, it looks like lld and gold are giving different resolutions to the symbols, which is presumably creating this issue: (first file is with lld and second is with gold) $ diff a.out.resolution.txt gold/ 4c4 < -r=a.o,__llvm_profile_raw_version,plx --- > -r=a.o,__llvm_profile_raw_version,l 8,9c8,9 <

RFC: (Thin)LTO with Linker Scripts At the last US LLVM Developers' Meeting, we presented [1] a proposal for linker script support in (Thin)LTO. In this RFC, I would like to describe the proposal in more detail and invite the community's feedback, so we can build consensus on the upstream implementation. The end goal of this effort is to extend the benefits of (Thin)LTO, including

The problem is that ThinLTO is not dropping the non-prevailing definitions, and they end up being emitted into the object file for b.o. $ ../ra/bin/llvm-dis -o - b.o0.0.preopt.bc | grep __llvm_prof $__llvm_profile_raw_version = comdat any $__llvm_profile_filename = comdat any @__llvm_profile_raw_version = constant i64 72057594037927940, comdat @__llvm_profile_filename = constant [19 x i8]

Thanks Peter, your patch does fix the reproducer. I filed https://bugs.llvm.org/show_bug.cgi?id=37422 to track this bug. I have no clue on how to resolve the tests - whether further cleanup is required in the code or in the tests. But if Teresa or you cannot get to it, I can, with some help, take a crack at fixing the tests. On Wed, May 9, 2018 at 11:26 AM Peter Collingbourne <peter at

> On May 1, 2018, at 4:50 PM, Teresa Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Mehdi, thanks for the comments, responses and a tweaked proposal below. Teresa > > On Tue, May 1, 2018 at 11:37 AM, Mehdi AMINI <joker.eph at gmail.com <mailto:joker.eph at gmail.com>> wrote: > Hi, > > My main concern is this one: > > >

Le jeu. 3 mai 2018 à 15:52, Peter Collingbourne <peter at pcc.me.uk> a écrit : > > > On Thu, May 3, 2018 at 3:29 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Thu, May 3, 2018 at 3:08 PM Peter Collingbourne via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> On Thu, May 3, 2018 at 2:44 PM, Mehdi AMINI

Le mar. 1 mai 2018 à 16:50, Teresa Johnson <tejohnson at google.com> a écrit : > Hi Mehdi, thanks for the comments, responses and a tweaked proposal below. > Teresa > > On Tue, May 1, 2018 at 11:37 AM, Mehdi AMINI <joker.eph at gmail.com> wrote: > >> Hi, >> >> My main concern is this one: >> >> > Currently, I am emitting the summary