search for: addpassestoemitmc

Hi llvmdev, I am still using llvm 2.9. The function addPassesToEmitMC in 3.0 takes a extra parameter to specify the raw stream for the emitter to emit code. However in 2.9, there is no such a parameter. How shall I do if want to pass a raw_stream object? llvm 2.9 // addPassesToEmitMC - Add passes to the specified pass manager to get /// machine code emitted with the...

...look like the rest of the Doxygen comments: /// methodName - Use complete sentences starting with caps and ending with /// periods. + /// get machine code emitted. This method should returns true if fails. + /// It fills the MCContext Ctx pointer used to build MCStreamer. + /// + virtual bool addPassesToEmitMC(PassManagerBase &PM, + MCContext *&Ctx, + CodeGenOpt::Level OptLevel, + bool DisableVerify = true) { + return true; + } Ditto. + /// get machine code emitted. This method should returns t...

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

...ercentages are from a Release+Profiling > build. > > For 1k iterations, the test took about 640ms on my desktop machine, ie > 0.64ms per module. Looking at the profiling results, it looks like about > 47% of the time is spent in PassManagerImpl::run, and another 47% is spent > in addPassesToEmitMC, which feels like it could be avoided by doing that > just once. Of the time spent in PassManagerImpl::run, about 35% is spent > in PassManager overhead such as initializeAnalysisImpl() / > removeNotPreservedAnalysis() / removeDeadPasses(). > > For 10k iterations, the test took abou...

...a big difference), and the percentages are from a Release+Profiling build. For 1k iterations, the test took about 640ms on my desktop machine, ie 0.64ms per module. Looking at the profiling results, it looks like about 47% of the time is spent in PassManagerImpl::run, and another 47% is spent in addPassesToEmitMC, which feels like it could be avoided by doing that just once. Of the time spent in PassManagerImpl::run, about 35% is spent in PassManager overhead such as initializeAnalysisImpl() / removeNotPreservedAnalysis() / removeDeadPasses(). For 10k iterations, the test took about 12.6s, or 1.26ms per m...

...comments: > /// methodName - Use complete sentences starting with caps and ending with > /// periods. > > +  /// get machine code emitted.  This method should returns true if fails. > +  /// It fills the MCContext Ctx pointer used to build MCStreamer. > +  /// > +  virtual bool addPassesToEmitMC(PassManagerBase &PM, > +                                 MCContext *&Ctx, > +                                 CodeGenOpt::Level OptLevel, > +                                 bool DisableVerify = true) { > +    return true; > +  } > > Ditto. > > +  /// get machine...

The passes run are determined by TargetMachine::adPassesToEmitMachineCode (or addPassesToEmitMC in the case of MCJIT), which is called from the JIT constructor. You can step through that to see where the passes are coming from or you can create a custom target machine instance to control it. -Andy -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs...

...ic of lots of API calls are not intuitively understandable. Best Regards --Armin Kaylor, Andrew wrote: > I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an in-memory object file image (using addPassesToEmitMC) and then loads and links it for execution. > > If there's some particular detail you don't like in the way this is happening, you might be able to generate a file as you have and then use the RuntimeDyld interface to load it. The llvm-rtdyld tool does something like this. > >...

I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an in-memory object file image (using addPassesToEmitMC) and then loads and links it for execution. If there's some particular detail you don't like in the way this is happening, you might be able to generate a file as you have and then use the RuntimeDyld interface to load it. The llvm-rtdyld tool does something like this. -Andy -----Origin...

...>> >> 1. In your opinion where does a “backend" start? >> >> For instance, does a backend starts at llc or at ISel? > > In practical terms I'd say the "backend" is all the passes added by LLVMTargetMachine::addPassesToEmitFile()/LLVMTargetMachine::addPassesToEmitMC()… I can buy that definition of backend :). > So I don't see any "contract" problems here whether we have some IR passes before ISel or not… I basically don’t mind having IR passes before ISel or not, the clarification I am interested in is the contract for ISel. I want to be ab...

...gt; Best Regards >> >> --Armin >> >> >> >> Kaylor, Andrew wrote: >>> I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an in-memory object file image (using addPassesToEmitMC) and then loads and links it for execution. >>> >>> If there's some particular detail you don't like in the way this is happening, you might be able to generate a file as you have and then use the RuntimeDyld interface to load it. The llvm-rtdyld tool does something like...

...introduced to the "static ExecutionEngine *create(...)" method, allowing the lli tool to use the MCJIT with the optional flag "-mcjit". The MCJIT can now execute little functions with no relocation (like add(a,b) => a+b), to do that some modifications have been made : - The addPassesToEmitMC method has been added to TargetMachine class. It fills the MCContext pointer so we can build the MCJITStreamer. - The Finish method of MCAssembler have a new optional argument "Writer" to allow a custom MCJITObjectWriter to be used. Can you give us some feedbacks on the general idea and...

....cpp:271:3: error: expected unqualified-id before ‘return’ /usr/home/yuri/llvm-svn/llvm/lib/CodeGen/LLVMTargetMachine.cpp:272:1: error: expected declaration before ‘}’ token /usr/home/yuri/llvm-svn/llvm/lib/CodeGen/LLVMTargetMachine.cpp: In member function ‘virtual bool llvm::LLVMTargetMachine::addPassesToEmitMC(llvm::PassManagerBase&, llvm::MCContext*&, llvm::raw_ostream&, llvm::CodeGenOpt::Level, bool)’: /usr/home/yuri/llvm-svn/llvm/lib/CodeGen/LLVMTargetMachine.cpp:250:3: warning: control reaches end of non-void function [-Wreturn-type] rm: /usr/home/yuri/llvm-svn/llvm-objects/lib/CodeGen...

Hi, I would like your opinions on the contract we have between the LLVM IR and the backends. * Context * Right now, the backends are supposed to be able to perform instruction selection on any valid LLVM IR. Although this is *not* something I want to change for GlobalISel, I thought I brought that up on the mailing list to discuss the implications. In particular, in the past, some people

...understandable. > > Best Regards > > --Armin > > > > Kaylor, Andrew wrote: >> I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an in-memory object file image (using addPassesToEmitMC) and then loads and links it for execution. >> >> If there's some particular detail you don't like in the way this is happening, you might be able to generate a file as you have and then use the RuntimeDyld interface to load it. The llvm-rtdyld tool does something like this. &...

...t;>> >>> Kaylor, Andrew wrote: >>>> >>>> I'm not sure I understand your use case, but MCJIT (as opposed to the >>>> legacy JIT) does almost exactly what you're asking for. It generates an >>>> in-memory object file image (using addPassesToEmitMC) and then loads and >>>> links it for execution. >>>> >>>> If there's some particular detail you don't like in the way this is >>>> happening, you might be able to generate a file as you have and then use the >>>> RuntimeDyld inter...

Hi, I'm building LLVM IR. I'd like to compile this IR to native code (I don't want JIT) and immediately load it to execute. So far, I've the following: 1) I can emit the IR to native assembly/object file doing the same thing llc does (using TargetMachine::addPassesToEmitFile). 2) I can dynamically load a precompiled .so file (using llvm::sys::DynamicLibrary::getPermanentLibrary),

...;static ExecutionEngine *create(...)" method, allowing the lli > tool to use the MCJIT with the optional flag "-mcjit". > > The MCJIT can now execute little functions with no relocation (like > add(a,b) => a+b), to do that some modifications have been made : > - The addPassesToEmitMC method has been added to TargetMachine class. > It fills the MCContext pointer so we can build the MCJITStreamer. > - The Finish method of MCAssembler have a new optional argument > "Writer" to allow a custom MCJITObjectWriter to be used. > > Can you give us some feedbacks...

Hi, I know using llc i can print machine code (-print-machineinstrs). How can i print machine code using llvm c++ api.. i looked into llc code but not able to find it.. Thanks & Regards, Pachauri

On Nov 13, 2012, at 6:15 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > The passes run are determined by TargetMachine::adPassesToEmitMachineCode (or addPassesToEmitMC in the case of MCJIT), which is called from the JIT constructor. You can step through that to see where the passes are coming from or you can create a custom target machine instance to control it. Assuming I were to create a TargetMachine, any small examples of controlling it I could see? On Nov...