search for: addpassestoemitfil

...:entry* _arch = llvm::TargetMachineRegistry::getClosestTargetForJIT(Err); std::string FeaturesStr; llvm::TargetMachine* target(_arch->CtorFn(*_module, FeaturesStr)); assert(target && "Could not allocate target machine!"); std::ostringstream os; target->addPassesToEmitFile(*_passManager, os, llvm::TargetMachine::AssemblyFile, true); target->addPassesToEmitFileFinish(*_passManager, 0, true); However, in newer versions of llvm, like 2.5 that I'm testing now, I had to change the code to something like this: std::string Err; const llvm::TargetMac...

...ineRegistry::getClosestTargetForJIT(Err); > >    std::string FeaturesStr; >    llvm::TargetMachine* target(_arch->CtorFn(*_module, FeaturesStr)); >    assert(target && "Could not allocate target machine!"); > >    std::ostringstream os; > >    target->addPassesToEmitFile(*_passManager, os, > llvm::TargetMachine::AssemblyFile, true); >    target->addPassesToEmitFileFinish(*_passManager, 0, true); > > > > However, in newer versions of llvm, like 2.5 that I'm testing now, I > had to change the code to something like this: > > >  ...

Hi, I am using TargetMachine::addPassesToEmitFile to write out x86-64 assembly. However, the generated assembly uses the AT&T syntax. Is there a way to switch to the Intel syntax? Thanks, Frank

...rgetForJIT(Err); > > >    std::string FeaturesStr; > >    llvm::TargetMachine* target(_arch->CtorFn(*_module, FeaturesStr)); > >    assert(target && "Could not allocate target machine!"); > > >    std::ostringstream os; > > >    target->addPassesToEmitFile(*_passManager, os, > > llvm::TargetMachine::AssemblyFile, true); > >    target->addPassesToEmitFileFinish(*_passManager, 0, true); > > > However, in newer versions of llvm, like 2.5 that I'm testing now, I > > had to change the code to something like this: > &g...

...>> 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 arbitrary >> MCStreamer as input. Without such a feature when compiling bytecode >> (i.e. emulating llc -filetype=obj behaviour) I have to emit .s file >> first, disassemble it and feed to custom MCStreamer. That'll hopely work >> but it's ugly. > &gt...

Hi folks, just installed the new llvm 1.9 build and noticed that my code no longer worked. It seems something has changed with addPassesToEmitFile(). First, the arguments to that method changed so that it no longer takes a PassManager, but only a FunctionPassManager. Instead there is a addPassesToEmitWholeFile() method, but that is marked as optional, and when I change my code to use that there is no output (only an empty file). I...

I wanted to bring this up again. I still try to get access to the assembler of a jit-compiled function/module using llvm 3.8 and later. In 3.8 the interface to addPassesToEmitFile has changed and my old method doesn't work any more. In principle one gets the asm with targetMachine->addPassesToEmitFile( PM , *OS , llvm::TargetMachine::CGFT_AssemblyFile ) where *OS is a raw_pwrite_stream. The problem is that I only find use cases of raw_pwrite_stream where the d...

...7 branch). For example > llc -filetype=obj whatever.bc doesn't work in Linux environment anymore (well it wasn't fully implemented before but it worked for simple bytecodes in 2.6). I used to generate code by creating TargetMachine and FunctionPassManager, then calling TargetMachine::addPassesToEmitFile, then adding my own CodeEmitter/CodeWriter (exactly like llc does). I have to say I always hated code emitter interface but at least it worked for me. Now LLVMTargetMachine::addPassesToEmitFile has changed. It adds its own code emitter and it's always MachOCodeEmitter which of course I don...

On Sun, 21 Jan 2007, Marcel Weiher wrote: > just installed the new llvm 1.9 build and noticed that my code no > longer worked. It seems something has changed with > addPassesToEmitFile(). First, the arguments to that method changed so > that it no longer takes a PassManager, but only a > FunctionPassManager. Instead there is a addPassesToEmitWholeFile() > method, but that is marked as optional, and when I change my code to > use that there is no output (only an emp...

I can use llc to compile my IR module to amdgcn with some non-zero output. However, if try to write the output (assembly or object) to a string (via buffer_ostream) the resulting string has always zero length. Here the code changes I do: Original llc:       if (Target->addPassesToEmitFile(PM, *OS,                                       DwoOut ? &DwoOut->os() : nullptr,                                       FileType, NoVerify, MMIWP)) Now, with this tiny change I was hoping to write to a string instead of the output stream defined by the command line parameters: std::str...

Note that raw_fd_ostream is not seekable, and hence will not be suitable as addPassesToEmitFile output stream. 2016-02-22 18:27 GMT+02:00 Rafael Espíndola <llvm-dev at lists.llvm.org>: > On 22 February 2016 at 11:16, Frank Winter <fwinter at jlab.org> wrote: > > TargetMachine::CGFT_AssemblyFile is exactly what I am trying to write > out. > > I see. > >...

On Thu, Jun 21, 2007 at 04:37:14PM -0700, Devang Patel wrote: > > On Jun 21, 2007, at 4:13 PM, Dan Gohman wrote: > > > Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm > > working with code that uses a plain PassManager and want it to > > generate > > code, are there any options better than doing this: > > That's what FPPassManager does (include/llvm/PassManagers.h) . > Function pass...

...itting 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 arbitrary >>> MCStreamer as input. Without such a feature when compiling bytecode >>> (i.e. emulating llc -filetype=obj behaviour) I have to emit .s file >>> first, disassemble it and feed to custom MCStreamer. That'll hopely work >>> but it's...

...;re in the same page but just in case we aren't I'm trying to provide support for built-in functions at compilation time. Some functions can be expressed in LLVM and others only in the target language. For the first group I'm trying to inline the implementation in a module pass added in addPassesToEmitFile. For the second I'm thinking of using an asm node to insert the implementation. My first question was if the approach is correct; the second was how to add the module pass if addPassesToEmitFile gets a FunctionPAssManager from otp. Thanks, Javier On Mon, 20 Jul 2009 08:33:44 -0500, Kenneth...

...; >>> 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 arbitrary > MCStreamer as input. Without such a feature when compiling bytecode > (i.e. emulating llc -filetype=obj behaviour) I have to emit .s file > first, disassemble it and feed to custom MCStreamer. That'll hopely work > but it's ugly. What are you trying to d...

...t works as well as llc -filetype=obj. > >> 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 arbitrary MCStreamer as input. Without such a feature when compiling bytecode (i.e. emulating llc -filetype=obj behaviour) I have to emit .s file first, disassemble it and feed to custom MCStreamer. That'll hopely work but it's ugly. -- Best Regards Peter Shugalev

...;> llc -filetype=obj whatever.bc > doesn't work in Linux environment anymore (well it wasn't fully > implemented before but it worked for simple bytecodes in 2.6). > > I used to generate code by creating TargetMachine and > FunctionPassManager, then calling TargetMachine::addPassesToEmitFile, > then adding my own CodeEmitter/CodeWriter (exactly like llc does). I > have to say I always hated code emitter interface but at least it worked > for me. > > Now LLVMTargetMachine::addPassesToEmitFile has changed. It adds its own > code emitter and it's always MachOCodeEm...

TargetMachine::addPassesToEmitFile(..) requires as its 2nd argument an raw_pwrite_stream. Is it possible to create such a thing which either writes into a standard string or streams to outs() ? Thanks,

Chris Lattner wrote: >> The TargetMachine class has a method 'addPassesToEmitMachineCode', that's >> suitable for that, but that method also requires an instance of >> MachineCodeEmitter. > > Actually, you probably want to plug into the addPassesToEmitFile API, when > FileType is set to ObjectFile. X86TargetMachine::addPassesToEmitFile > demonstrates how to do this. Ok. Note, however, that online HTML docs for "llc", as well as "llc.pod" in the current CVS don't mention the "filetype" option that is used to...

Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm working with code that uses a plain PassManager and want it to generate code, are there any options better than doing this: /** * Wrapper class to run a FunctionPassManager as a ModulePass so that it * can be added to a plain PassManager. */ class Fun...