similar to: exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline

Displaying 20 results from an estimated 20000 matches similar to: "exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline"

2018 Apr 10
0
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
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
2018 Apr 11
1
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
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.
2018 Apr 10
3
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial 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
2018 Apr 11
0
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
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
2018 Apr 11
1
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
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:*
2018 Apr 11
0
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
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
2018 Apr 11
0
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
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
2018 Apr 11
0
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
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.
2018 Apr 11
2
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial 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
2018 Apr 11
2
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
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. >> >> -
2018 Apr 11
3
exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization pipeline
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
2017 May 01
3
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
2017 Jan 16
4
Your help needed: List of LLVM Open Projects 2017
> On Jan 16, 2017, at 1:47 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Mon, Jan 16, 2017 at 1:25 PM, Davide Italiano <davide at freebsd.org <mailto:davide at freebsd.org>> wrote: > On Mon, Jan 16, 2017 at 12:31 PM, Sean Silva via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Do we
2017 Apr 25
2
RFC: Moving the module summary into the irsymtab
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 direction with this. Basically I want to move the summary into the irsymtab that we will be storing to disk after D32061 lands. This would help solve a number of problems: - To read a summary, you need to read all summaries in a
2018 Mar 27
2
[pre-RFC] Data races in concurrent ThinLTO processes
Hi Peter, Thank you for the clarification ☺. I’m sure you have a very good understanding of how much efforts it will take to write a patch for legacy C LTO to implement caching the same way it’s done in new C++ LTO API. How easy/difficult do you think it will be (very roughly, in LOC)? Do you anticipate that a lot of existing legacy C LTO infrastructure will have to be rewritten? Could this also
2018 Mar 27
0
[pre-RFC] Data races in concurrent ThinLTO processes
On Mon, Mar 26, 2018 at 7:34 PM, <katya.romanova at sony.com> wrote: > Hi Peter, > > > > Thank you for the clarification J. > > > > I’m sure you have a very good understanding of how much efforts it will > take to write a patch for legacy C LTO to implement caching the same way > it’s done in new C++ LTO API. How easy/difficult do you think it will be >
2018 Mar 27
0
[pre-RFC] Data races in concurrent ThinLTO processes
On Mon, Mar 26, 2018 at 6:03 PM, <katya.romanova at sony.com> wrote: > Hi Steven, > > Look at my replies inline (below your comments). > > Katya. > > > > *From:* stevenwu at apple.com <stevenwu at apple.com> > *Sent:* Thursday, March 22, 2018 4:46 PM > *To:* Romanova, Katya <katya.romanova at sony.com> > *Cc:* Teresa Johnson <tejohnson at
2018 Mar 27
4
[pre-RFC] Data races in concurrent ThinLTO processes
Hi Steven, Look at my replies inline (below your comments). Katya. From: stevenwu at apple.com <stevenwu at apple.com> Sent: Thursday, March 22, 2018 4:46 PM To: Romanova, Katya <katya.romanova at sony.com> Cc: Teresa Johnson <tejohnson at google.com>; Mehdi AMINI <joker.eph at gmail.com>; Rafael Avila de Espindola <rafael.espindola at gmail.com>; Peter Collingbourne
2016 Mar 23
0
[RFC] Lazy-loading of debug info metadata
On Tue, Mar 22, 2016 at 9:48 PM, Duncan Exon Smith <dexonsmith at apple.com> wrote: > > On Mar 22, 2016, at 8:04 PM, David Blaikie <dblaikie at gmail.com> wrote: > > +pcc, who had some other ideas/patch out for improving memory usage of > debug info > +Reid, who's responsible for the windows/CodeView/PDB debug info which is > motivating some of the ideas about
2018 Mar 27
1
[pre-RFC] Data races in concurrent ThinLTO processes
Hi Steven and Peter, I think we resolved all the misunderstanding/concerns that we had with the proposal and decided that we don’t have to implement heavy-weight synchronization solutions (such as read-write locks, etc). Lightweight solution is expected to work on MacOS and Windows (however, there might be issues with Windows supporting non-NTFS file systems). There are two options for the