similar to: [LLVMdev] Function-at-a-time Processing

Dear David, Dumb question: Would it be easier to write an LLVM tool that took the large IR file and divided it into several smaller IR files that could then be code-generated separately? -- John T. David Greene wrote: > We process very large programs and it is not unusual for the IR for some > compilation unit to exceed system memory. With some hacking in LLVM 2.5 > I was able to

Chris Lattner wrote: > On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: > >>>> New method of emitting object code is ok for me. But it is still >>>> experimental, isn't it? >>> Yes. >> Thank you for answers! >> >> Now there is a way to implement what I'd like to. But it would be MUCH >> better if

On Mar 27, 2010, at 1:50 PM, Peter Shugalev wrote: > Chris Lattner wrote: >> On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: >> >>>>> New method of emitting object code is ok for me. But it is still >>>>> experimental, isn't it? >>>> Yes. >>> Thank you for answers! >>> >>> Now there is a way to implement

I checked recent revisions 138624 and 138620 and both produce this log with gcc-4.6.0 on FreeBSD-8.2-STABLE amd64: gmake[2]: Entering directory `/usr/home/yuri/llvm-svn/llvm-objects/lib/CodeGen' llvm[2]: Compiling LLVMTargetMachine.cpp for Release build /usr/home/yuri/llvm-svn/llvm/lib/CodeGen/LLVMTargetMachine.cpp:253:3: error: ‘AsmStreamer’ does not name a type

Dear LLVM, Might be a easy question for someone, but not for me now. Consider there is a TargetMachine instance. Having this target, how could you get a corresponding Mangler class instance? Mangler depends on MCContext, which is connected with LLVMTargetMachine inherited from TargetMachine. However, LLVMTargetMachine is only available for targets machines implementations, and not available

On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant <meurant.olivier at gmail.com> wrote: > New patch taking Eli's comments into account. Comments inline. If you have commit access, I'd fire away. If not, I can. diff --git include/llvm/MC/MCAssembler.h include/llvm/MC/MCAssembler.h index 07ca070..afff96e 100644 --- include/llvm/MC/MCAssembler.h +++ include/llvm/MC/MCAssembler.h

Hello all, I'm trying to hack MCJIT::emitObject to optionally output the corresponding text assembly associated with the object code being emitted (if a debug flag is set in the app/dev environment which is hosting LLVM). I attempted to do this by adding another AsmPrinter pass to the PassManager, but this runs into all sorts of problems because there's only once MCContext and one

On Thu, May 23, 2013 at 8:13 AM, Justin Holewinski < justin.holewinski at gmail.com> wrote: > That sounds like a missed multi-threading issue with LLVM. I can't > imagine why the user should be forced to serialize creation of MCContext > objects. I would suggest filing a bug for this. A simple lock probably > wouldn't be too detrimental to performance here, since

On Mar 27, 2010, at 12:49 PM, Peter Shugalev wrote: >>> >>> New method of emitting object code is ok for me. But it is still >>> experimental, isn't it? >> >> Yes. > > Thank you for answers! > > Now there is a way to implement what I'd like to. But it would be MUCH > better if LLVMTargetMachine::addPassesToEmitFile could take

Chris Lattner wrote: > On Mar 27, 2010, at 11:56 AM, Peter Shugalev wrote: > >>>> What exactly is expected to be coming? Will it be the same way MachO is >>>> currently implemented but with some flexibility to supply my own class >>>> to do actual object output? Or just a return of old ObjectCodeEmitter? >>> We're integrating a full assembler

Hello all, I am a LLVM newer who want to add a new backend(EBC) into LLVM. After coping the related files from another target and modifying it, I meet a problem when I build the project. The error message is as follows: ================================================================ [ 94%] Built target llvm-dis Linking CXX executable ../../bin/llvm-mc Undefined symbols:

Hi ! > Sorry I missed responding to this email sooner. No problem, I was not in a hurry. :) > The approximate approach I had in mind sounds like what you describe, Ok Cool ! > I have been meaning to do this, but won't have time for a couple weeks I suspect. So I will give it a try. :) I was able to quickly hack a JITObjectWriter and I am able to execute simple functions (with

Compiling the IR code at http://pastebin.com/hSwdLdD0 for target triple x86_64-apple-macosx fails with : assert(Symbol->isUndefined() && "Cannot define a symbol twice!"); `anon'::MCMachOStreamer::EmitLabel(llvm::MCSymbol * Symbol) llvm::DwarfDebug::emitDebugInfo() Line 1752 + 0x3c bytes C++ llvm::DwarfDebug::endModule() Line 865 C++

Yeah, that's probably how I'd do it. Might be useful if you guys want to contribute that as a command line option Kevin. -eric On Tue, Jun 24, 2014 at 3:03 PM, Kevin Modzelewski <kmod at dropbox.com> wrote: > We do this in Pyston using a JITEventListener that just disassembles the > output; it's "it works let's move on"-quality: >

Hi everyone, I downloaded the latest version of LLVM PTX backend from http://www.prog.uni-saarland.de/projects/anysl and made the required changes to all the files mentioned in the README. But I get the following error when I compile it. llvm[3]: Compiling PTXBackend.cpp for Release build In file included from PTXBackend.h:70:0, from PTXBackend.cpp:36: PTXPasses.h: In constructor

I do have an opinion, but don't have enough time to comment in much depth. The approximate approach I had in mind sounds like what you describe, though, the JITObjectWriter is the core piece, the other pieces probably fall into place as it becomes obvious if they are needed. It should be pretty straightforward to bring up something which works for running code with no external symbols, if you

New patch taking Eli's comments into account. Olivier. On Tue, Jul 20, 2010 at 11:09 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Jul 20, 2010 at 1:36 PM, Olivier Meurant > <meurant.olivier at gmail.com> wrote: >>> Seems reasonable, but I haven't looked at the code yet. I would >>> suggest trying to split your work up into separate

(NPM: new pass manager; LPM: legacy pass manager) Hello, community While we're still working towards using NPM for optimizer pipeline by default, we still don't have a machine pass interface and the corresponding machine pass manager using NPM. The potential benefits using NPM aside, this inhibits us from making any progress on deprecating LPM for the codegen pipeline which blocks

Currently, the MachO and ELF Writers and MachineCodeEmitters are hard-coded into LLVMTargetMachine and llc. In other words, the 'object file generation' capabilities of the Common Code Generator are not generic. LLVMTargetMachine::addPassesToEmitFile explicitly checks whether the derived backend TargetMachine implements one of getMachOWriterInfo or getELFWriterInfo, and returns a

New patch. Thanks for all of your comments ! > Comments inline. If you have commit access, I'd fire away. If not, I can. I don't have commit access, if you find it ok, please commit it. :) Olivier. On Wed, Jul 21, 2010 at 6:56 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant > <meurant.olivier at gmail.com>