similar to: [LLVMdev] Handling of built-in functions

Hi Daniel, Thanks for the reply. If I understand correctly, your suggestion is to have the backend call a library that handles the built-in functions. Would the calls need to be lowered and redirected (e.g. by a big switch statement or a jump table) to the corresponding function in the library? Thanks, Javier On 7/20/2009 12:11 AM, Daniel Dunbar wrote: > Hi Javier, > > I'm not

The issue is that there is no runtime function. I'm not sure we'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

Hi Javier, I'm not the right person to answer your question, but since no one else took it: I believe this is a situation where the backend would typically emit a call the the compiler's runtime library (e.g., libgcc). While it isn't currently completely wired up, we do have our own compiler runtime library available under the compiler-rt project in the LLVM repo. - Daniel On Thu,

I don't see why. Your compiler would just do a declare and then a call, and your runtime function gets called. On Mon, Jul 20, 2009 at 4:13 AM, Javier Martinez<javier at jmartinez.org> wrote: > Hi Daniel, > > Thanks for the reply. If I understand correctly, your suggestion is to have > the backend call a library that handles the built-in functions. Would the > calls need

If you add an ASM node, you won't be able to JIT the result. I don't know if you care about that or not, but ASM nodes aren't supported by the execution engine. (If you do want to JIT, you could always dump the machine code to memory and link its location to a global using ExecutionEngine::addGlobalMapping), and then JIT whatever needs to call it. Obviously, it won't get inlined

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

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 FunctionPassManagerModulePass : public ModulePass { FunctionPassManager

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

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 manager itself is a module level pass.

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

Hi, Just realized that ability to generate static object code (e.g. ELF w/o using JIT) is no longer available in 2.7 (at least in release_27 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

Hello, I'm trying to catch assembly output and do some formatting for its presentation while being executed. I face a problem, which is clear from the error, although I have no clue on how to do it otherwise. If generating the code for its asm output and then for jit execution I get: ********** static llvm::MachineFunction& llvm::MachineFunction::construct(const llvm::Function*, const

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 26, 2010, at 6:24 PM, Peter Shugalev wrote: > Hi, > > Just realized that ability to generate static object code (e.g. ELF w/o > using JIT) is no longer available in 2.7 (at least in release_27 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

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, I would like to know how to go about printing the x86 assembly output for a compiled function (I'm using the JIT). I saw there is a X86IntelAsmPrinter on doxygen. However, it takes several arguments I don't know how to fill in. Is there a helper function to create such a pass? Once I have the pass created, do I just add it to a FunctionPassManager? Thank you for your time, -

Hi! Is it possible that you add an example how to write a .o with llvm? Just like examples/ModuleMaker but instead of printing to stdout writing a .o file as starting point for the new MC functionality. -Jochen

Jochen Wilhelmy <j.wilhelmy at arcor.de> writes: > Is it possible that you add an example how to write a .o with llvm? +1

Hello, I'm having trouble getting LLVM to use UMUL_LOHI instead of MUL for unsigned integers. In the TargetLowering constructor I have: setOperationAction(ISD::MUL, MVT::i32, Expand); setOperationAction(ISD::SMUL_LOHI, MVT::i32, Legal); setOperationAction(ISD::UMUL_LOHI, MVT::i32, Legal); The problem seems to be with the code in LegalizeOp() in LegalizeDAG.cpp. Here's a snipet of