similar to: [LLVMdev] LTOModule::parseSymbols not handling GlobalAlias

On 19 September 2014 15:54, Steven Wu <stevenwu at apple.com> wrote: > Yes, we don’t need to edit the assembly in the file, but we need to modified the CHECK line to reflect the output of current llvm-dis. I was talking about updating the CHECK in all the previous version. Does that make sense? Yes, the CHECK lines would have to be updated, but that seems like a pretty small annoyance.

Hello. I work at Apple on our linker. We are working to improve support for llvm in our tools. A while back Devang created <llvm/LinkTimeOptimizer.h> a C++ interface which allows the linker to process llvm bitcode files along with native mach-o object files. For the next step we'd like our other tools like nm, ar, and lipo to be able to transparently process bitcode files

While looking at adding a TargetOption, I saw that there is significant overlap between the options listed in llvm/CodeGen/CommandFlags.h (which are used to set TargetOptions in llc and opt) and the options in LTOModule.cpp. There are only a few extra options in CommandFlags.h, and all target options used by LTO are there. Would it make sense to use CommandFlags.h in LTOModule as well? - Stephen

While looking at adding a new TargetOption, I saw that there is significant overlap between the options listed in llvm/CodeGen/CommandFlags.h (which are used to set TargetOptions in llc and opt) and the options in LTOModule.cpp. There are only a few extra options in CommandFlags.h, and all target options used by LTO are there. Would it make sense to use CommandFlags.h in LTOModule as well? -

On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: > Hi folks, > > I just committed a new backend for the Hexagon processor. After committing, I was able to successfully check out, build and test with the new changes. The x86_64 build on the buildbot is failing, however. Here's the build error: > > llvm[2]: Linking Debug+Asserts executable llvm-mc >

On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: > > On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: > >> Hi folks, >> >> I just committed a new backend for the Hexagon processor. After >> committing, I was able to successfully check out, build and test with >> the new changes. The x86_64 build on the buildbot is failing, >> however.

On Dec 12, 2011, at 2:41 PM, Eric Christopher wrote: > > On Dec 12, 2011, at 2:36 PM, Tony Linthicum wrote: > >> On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: >>> >>> >>> On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: >>> >>>> Hi folks, >>>> >>>> I just committed a new backend for the Hexagon

On Dec 12, 2011, at 2:36 PM, Tony Linthicum wrote: > On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: >> >> >> On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: >> >>> Hi folks, >>> >>> I just committed a new backend for the Hexagon processor. After committing, I was able to successfully check out, build and test with the new changes.

On Dec 12, 2011, at 2:51 PM, Tony Linthicum wrote: > On 12/12/2011 4:49 PM, Eric Christopher wrote: >> >> >> On Dec 12, 2011, at 2:41 PM, Eric Christopher wrote: >> >>> >>> On Dec 12, 2011, at 2:36 PM, Tony Linthicum wrote: >>> >>>> On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: >>>>> >>>>>

On 12/12/2011 4:49 PM, Eric Christopher wrote: > > On Dec 12, 2011, at 2:41 PM, Eric Christopher wrote: > >> >> On Dec 12, 2011, at 2:36 PM, Tony Linthicum wrote: >> >>> On 12/12/2011 4:28 PM, Jakob Stoklund Olesen wrote: >>>> >>>> On Dec 12, 2011, at 2:12 PM, Tony Linthicum wrote: >>>> >>>>> Hi folks,

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

Compiled the 3.0.0 version of the source code , then tried lli --use-mcjit irfile.txt On both windows and linux, I got: LLVM ERROR: Unknow object format. If I omit the -use-mcjit option, the command works well. It seems to me that something about MCJIT is broken in the 3.0.0 version. Also tried to initialize an ExecutionEngine from code, got errors like "Target does not support MC

I'm hitting this. Is there ETA for the fix? Evan On Dec 12, 2011, at 2:58 PM, Daniel Dunbar wrote: > > On Dec 12, 2011, at 2:51 PM, Tony Linthicum wrote: > >> On 12/12/2011 4:49 PM, Eric Christopher wrote: >>> >>> >>> On Dec 12, 2011, at 2:41 PM, Eric Christopher wrote: >>> >>>> >>>> On Dec 12, 2011, at 2:36

Hello, I'm archiving a number of bitcode files via gold plugin based on LLVM 3.4. When I find a thumbv7 bitcode with a couple of module asms, I get a segfault in ARMAsmParser::parseDirectiveFnStart because getTargetStreamer returns NULL. Frankly, I don't see how this is supposed to work because as far as I understood LTOModule::addAsmGlobalSymbols only creates a RecordStreamer

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

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

When using the ARM cross compiler we've run into an issue with LTO and optimized libraries. Consider you have an optimized library opt.a, which contains a version of memcpy. Compiling with LTO (something like), clang myTest.c opt.a -flto -o myTest causes myTest.c to get compiled to bitcode. Then the bitcode gets passed to the linker. The linker looks through the bitcode (via

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.