similar to: [LLVMdev] LLVM Archive Format Extension Proposal

On Nov 21, 2012, at 8:55 AM, Relph, Richard wrote: > AMD would like to add new functionality to ranlib (and later ar and nm) and to the bits of LLVM Core that read (and later write) archives. > Herewith a terse summary of the change, which we want to improve support of OpenCL for multiple GPUs in a single run-time. > > Conceptually, a serialized archive is really 2 pieces: a few

On Nov 21, 2012, at 11:07 AM, Nick Kledzik <kledzik at apple.com<mailto:kledzik at apple.com>> wrote: On Nov 21, 2012, at 8:55 AM, Relph, Richard wrote: AMD would like to add new functionality to ranlib (and later ar and nm) and to the bits of LLVM Core that read (and later write) archives. Herewith a terse summary of the change, which we want to improve support of OpenCL for

On Wed, Nov 21, 2012 at 8:55 AM, Relph, Richard <Richard.Relph at amd.com> wrote: > AMD would like to add new functionality to ranlib (and later ar and nm) and > to the bits of LLVM Core that read (and later write) archives. > Herewith a terse summary of the change, which we want to improve support of > OpenCL for multiple GPUs in a single run-time. > > Conceptually, a

On Nov 21, 2012, at 12:09 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Wed, Nov 21, 2012 at 8:55 AM, Relph, Richard <Richard.Relph at amd.com> wrote: >> AMD would like to add new functionality to ranlib (and later ar and nm) and >> to the bits of LLVM Core that read (and later write) archives. >> Herewith a terse summary of the change, which we want

On Nov 21, 2012, at 4:00 PM, Relph, Richard wrote: > On Nov 21, 2012, at 11:07 AM, Nick Kledzik <kledzik at apple.com> wrote: >> On Nov 21, 2012, at 8:55 AM, Relph, Richard wrote: >>> AMD would like to add new functionality to ranlib (and later ar and nm) and to the bits of LLVM Core that read (and later write) archives. >>> Herewith a terse summary of the change,

On Mon, Dec 3, 2012 at 2:08 PM, Relph, Richard <Richard.Relph at amd.com> wrote: > On Nov 21, 2012, at 4:28 PM, "Relph, Richard" <Richard.Relph at amd.com> wrote: > >> On Nov 21, 2012, at 12:09 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: >> >>> Note that I plan to remove llvm/Bitcode/Archive once Object/Archive is >>>

On Nov 21, 2012, at 4:28 PM, "Relph, Richard" <Richard.Relph at amd.com> wrote: > On Nov 21, 2012, at 12:09 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> Note that I plan to remove llvm/Bitcode/Archive once Object/Archive is >> capable of replacing it. The llvm tools that don't write archives >> files have already been switched over

On Sat, Sep 10, 2016 at 6:25 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Sep 10, 2016, at 3:03 AM, Carsten Mattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> I tried building llvm, clang, lld, lldb from the 3.9 svn release >> branch with LTO, and some of the results were unexpected. >> >> I first tried to rebuild llvm

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

I tried building llvm, clang, lld, lldb from the 3.9 svn release branch with LTO, and some of the results were unexpected. I first tried to rebuild llvm with llvm-3.9, which has ThinLTO, by providing -DLLVM_ENABLE_LTO=Thin, but that failed very quickly, so I fell back to building with -DLLVM_ENABLE_LTO=On and using the system CC/CXX (gcc 6.1). The resulting installed build is many times bigger

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.

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

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

Hi Tobias The problem is that your static archive has a SYMDEF that is empty, so linker thinks the static library provided doesn't contain any symbol. The reason for that is you are using the `ranlib` from Xcode, which is too old to understand the new bitcode object files produced by llvm 10. There are lots of ways to fix that: * The standard way to create static library on macOS is to use

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

Eric, Once both AMD and Apple have advanced their respective internal LLVM versions past the point where AMDIL went in to LLVM TOT, then we can rip out all the conditional code and just have the one LLVM TOT. This is about managing the transition to that utopia… ;-) Until then, the choices really come down to having support for multiple LLVM versions in TOT, or having multiple backends.

Is there a convention for how the LLVM community prefers to have conditional compilation in code intended to be checked in to llvm.org? Our goal is a single code base that can support multiple LLVM revisions, including LLVM TOT. In the long run, of course, we'll simply be able to refer to the backend revision that corresponds to the revision of LLVM in use. If fixes between TOT and that older