similar to: ThinLTO and the C API

On Mon, 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

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. >From that view, it no longer makes sense to discuss "the plugin," or gold, or $AR,

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

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

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

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.

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

On Fri, May 15, 2015 at 12:02 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015-May-15, at 07:30, Teresa Johnson <tejohnson at google.com> wrote: > > > >>> a. Lazy Debug Metadata Linking: > >>> > >>> The prototype implementation included lazy importing of module-level > >>> metadata during the

Hi all, I am trying to figure out the best way to deal with non-default TargetMachine options when using ThinLTO with the LLVMgold.so plugin. (I'm adding support for ThinLTO to the LDC D compiler) Things like the target triple, target CPU and target CPU features, some floating point options like unsafe-fp-math, etc., those are (or can be made) explicit in the IR. Is that the way to go? We

Thanks for all the feedback and questions, answers below. Teresa On Thu, May 14, 2015 at 4:29 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015-May-13, at 11:44, Teresa Johnson <tejohnson at google.com> wrote: >> >> I've included below an RFC for implementing ThinLTO in LLVM, looking >> forward to feedback and questions. >>

On Fri, Aug 14, 2015 at 3:35 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Hi Teresa, > > Thanks for layout down a detailed proposal on top of the slides, it is > very instructive and very pleasant to read. > Hi Mehdi, Thanks! > > I have a few questions, none of which touches the ELF aspect! :) > I apologize if you already addressed them and I missed it (if

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

On 06/04/2015 07:43 AM, Teresa Johnson wrote: > On Wed, Jun 3, 2015 at 1:29 PM, Sean Silva <chisophugis at gmail.com> wrote: >> >> On Mon, 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

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

We didn't drop unnamed_addr. I just don't think weakodr_addr + unnamed_addr is safe to hide in all cases. I don't know if I interpreted local_unnamed_addr correctly but I think it is mostly the same in thinLTO for ld64. The code generator only looks at the individual module and ld64 will be in charge of merging all the symbols with autohide. It doesn't really help in this case.

> On Feb 7, 2018, at 4:03 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2018-02-07 12:45 GMT-08:00 Steven Wu <stevenwu at apple.com <mailto:stevenwu at apple.com>>: > > >> On Feb 7, 2018, at 12:36 PM, Mehdi AMINI <joker.eph at gmail.com <mailto:joker.eph at gmail.com>> wrote: >> >> > But it is interesting in

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

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

> On Feb 7, 2018, at 12:36 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > But it is interesting in general because according to the definition for local_unnamed_addr, the symbol has to be linkonce_odr to be auto hide as well. ThinLTO promotion can break that as well. > > What do you mean that the promotion can break that? > > The original description I found