similar to: Question about thinLTO

Displaying 20 results from an estimated 8000 matches similar to: "Question about thinLTO"

2017 Jul 12
2
Question about thinLTO
On Wed, Jul 12, 2017 at 10:19 AM, Teresa Johnson <tejohnson at google.com> wrote: > Hi Christu, > > Thanks for the note! > > On Wed, Jul 12, 2017 at 9:56 AM, Christudasan D via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hello, >> >> >> >> My impression on *thinLTO* when I first heard of it, (EuroLLVM2015) was >> about
2017 Jul 13
2
Question about thinLTO
On Thu, Jul 13, 2017 at 2:54 AM, Christudasan D <xander.cd at gmail.com> wrote: > Thank you Teresa. > > Yes, I would like to save the IR (*.bc and/or *.ll) after all > optimizations (especially thinLTO) are done and call *llc* separately. > Is there any specific document available online to see more about this > feature and various command-line switches that a compiler
2017 Jul 13
2
Question about thinLTO
On Thu, Jul 13, 2017 at 8:37 AM, Christudasan D <xander.cd at gmail.com> wrote: > > Hi Teresa, > > Yes, we plan to have our code at CG directly. > We use our own linker. That's the pain. We might only get a partial > benefit of thinLTO which occurs at compile time. > There is no compile-time only benefit of ThinLTO. You'll need the linker to interface with the
2015 May 14
2
[LLVMdev] RFC: ThinLTO Impementation Plan
So, what Alex is saying is that we have these tools as well and they understand bitcode just fine, as well as every object format - not just ELF. :) -eric On Thu, May 14, 2015, 6:55 AM Teresa Johnson <tejohnson at google.com> wrote: > On Wed, May 13, 2015 at 11:23 PM, Xinliang David Li > <xinliangli at gmail.com> wrote: > > > > > > On Wed, May 13, 2015 at
2015 May 14
2
[LLVMdev] RFC: ThinLTO Impementation Plan
The end goal is the ability to turn on thin-lto as easy as turning optimizations like -O2 or -O3 -- we want friendliness, very much :) David On Thu, May 14, 2015 at 11:14 AM, Eric Christopher <echristo at gmail.com> wrote: > I'm not sure this is a particularly great assumption to make. We have to > support a lot of different build systems and tools and concentrating on >
2015 May 14
2
[LLVMdev] RFC: ThinLTO Impementation Plan
On Wed, May 13, 2015 at 10:46 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > "ELF-wrapped bitcode" seems potentially controversial to me. > > What about ar, nm, and various ld implementations adds this requirement? > What about the LLVM implementations of these tools is lacking? > Sorry I can not parse your questions properly. Can you make it clearer? David
2015 May 14
4
[LLVMdev] RFC: ThinLTO Impementation Plan
On Thu, May 14, 2015 at 11:14 AM, Eric Christopher <echristo at gmail.com> wrote: > I'm not sure this is a particularly great assumption to make. Which part? > We have to > support a lot of different build systems and tools and concentrating on > something that just binutils uses isn't particularly friendly here. I think you may have misunderstood His point was exactly
2015 May 14
2
[LLVMdev] RFC: ThinLTO Impementation Plan
On Thu, May 14, 2015 at 12:53 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu, May 14, 2015 at 11:34 AM Daniel Berlin <dberlin at dberlin.org> > wrote: > >> On Thu, May 14, 2015 at 11:14 AM, Eric Christopher <echristo at gmail.com> >> wrote: >> > I'm not sure this is a particularly great assumption to make. >>
2015 May 14
5
[LLVMdev] RFC: ThinLTO Impementation Plan
The design objective is to make thinLTO mostly transparent to binutil tools to enable easy integration with any build system in the wild. 'Pass-through' mode with 'ld -r' instead of the partial LTO mode is another reason. David On Thu, May 14, 2015 at 7:30 AM, Teresa Johnson <tejohnson at google.com> wrote: > On Thu, May 14, 2015 at 7:22 AM, Eric Christopher
2015 May 14
2
[LLVMdev] RFC: ThinLTO Impementation Plan
On Thu, May 14, 2015 at 2:09 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu, May 14, 2015 at 1:35 PM Teresa Johnson <tejohnson at google.com> wrote: >> >> On Thu, May 14, 2015 at 1:18 PM, Eric Christopher <echristo at gmail.com> >> wrote: >> > >> > >> > On Thu, May 14, 2015 at 1:11 PM David Blaikie
2015 May 14
5
[LLVMdev] RFC: ThinLTO Impementation Plan
On Thu, May 14, 2015 at 1:18 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu, May 14, 2015 at 1:11 PM David Blaikie <dblaikie at gmail.com> wrote: >> >> On Thu, May 14, 2015 at 12:53 PM, Eric Christopher <echristo at gmail.com> >> wrote: >>> >>> >>> >>> On Thu, May 14, 2015 at 11:34 AM Daniel Berlin
2015 May 14
3
[LLVMdev] RFC: ThinLTO Impementation Plan
On Thu, May 14, 2015 at 2:09 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Thu, May 14, 2015 at 1:35 PM Teresa Johnson <tejohnson at google.com> > wrote: > >> On Thu, May 14, 2015 at 1:18 PM, Eric Christopher <echristo at gmail.com> >> wrote: >> > >> > >> > On Thu, May 14, 2015 at 1:11 PM David Blaikie
2015 May 15
4
[LLVMdev] RFC: ThinLTO Impementation Plan
There is no need for emitting the full symtab. I checked the overhead with a huge internal C++ source. The overhead of symtab + str table compared with byte code with debug is about 3%. More importantly, it is also possible to use the symtab also for index/summary purpose, which makes the space usage completely 'unwasted'. That gets into the details which will follow when patches are in.
2015 May 13
10
[LLVMdev] RFC: ThinLTO Impementation Plan
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
2015 May 30
2
[LLVMdev] Updated RFC: ThinLTO Implementation Plan
On Fri, May 29, 2015 at 8:01 AM, Teresa Johnson <tejohnson at google.com> wrote: > On Fri, May 29, 2015 at 6:56 AM, Alex Rosenberg <alexr at leftfield.org> > wrote: > > My earlier statement about wrapping things in a native object file held > in that it is controversial. It appears to be still central to your design. > > > > It may help to look at the
2015 Jun 03
2
[LLVMdev] Updated RFC: ThinLTO Implementation Plan
On Jun 1, 2015, at 6:34 AM, Teresa Johnson <tejohnson at google.com> wrote: > On Fri, May 29, 2015 at 6:15 PM, Sean Silva <chisophugis at gmail.com> wrote: >> >> >> On Fri, May 29, 2015 at 8:01 AM, Teresa Johnson <tejohnson at google.com> >> wrote: >>> >>> On Fri, May 29, 2015 at 6:56 AM, Alex Rosenberg <alexr at
2015 May 29
4
[LLVMdev] Updated RFC: ThinLTO Implementation Plan
On Fri, May 29, 2015 at 6:56 AM, Alex Rosenberg <alexr at leftfield.org> wrote: > My earlier statement about wrapping things in a native object file held in that it is controversial. It appears to be still central to your design. > > It may help to look at the problem from a different viewpoint: LLVM is not a compiler. It is a framework that can be used to make compiler-like tools.
2015 Aug 16
2
[LLVMdev] Updated RFC: ThinLTO Implementation Plan
Hi Mehdi, Saw David's response but wanted to add a bit more below. On Fri, Aug 14, 2015 at 11:14 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Aug 14, 2015, at 10:41 PM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Fri, Aug 14, 2015 at 3:35 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> Hi Teresa, >>
2015 Jun 03
4
[LLVMdev] Updated RFC: ThinLTO Implementation Plan
On Wed, Jun 3, 2015 at 4:19 AM, Dave Bozier <seifsta at gmail.com> wrote: > Hi Teresa, > > Thanks for providing this updated RFC. > >> For Sony's linker, are you using the gold plugin or libLTO interfaces? >> If the latter, I suppose some ThinLTO handling would have to be added >> to your linker (e.g. to invoke the LLVM hooks to write the stage-2 >>
2015 May 28
5
[LLVMdev] Updated RFC: ThinLTO Implementation Plan
As promised, here is an new version of the ThinLTO RFC, updated based on some of the comments, questions and feedback from the first RFC. Hopefully we have addressed many of these, and as noted below, will fork some of the detailed discussion on particular aspects into separate design doc threads. Please send any additional feedback and questions on the overall design. Thanks! Teresa Updated RFC