0

I'm using the LLVM-C API for a compiler project and need to emit object code from IR to an in memory buffer. I'm aware the JIT can do this, but the resulting code will be executed many times with different arguments so statically compiling once rather than JIT compiling each time makes more sense.

What I want is a buffer of object code which I can then set executable, likely by using mmap (but let me know if there's a simpler approach), and then run.

I've found the function LLVMTargetMachineEmitToMemoryBuffer which seems to do the first part of what I need, but it requires an existing LLVM memory buffer type to write into. From what I can tell I want LLVMCreateMemoryBufferWithRange for this, which takes a pointer to char and a size. But now I need to know how many bytes LLVMTargetMachineEmitToMemoryBuffer will write in advance to provide it with the correct buffer, which as it's generating object code from arbitrary IR could be arbitrarily large, so I feel like I'm taking the wrong approach here, but I'm unsure how else to go about this.

How can I achieve this using LLVM's API?

muke
  • 306
  • 2
  • 11
  • You can run the JITted code as often as you want. There isn't one function call, "compile and run", that ties the two together inseparably. Work through the kaleidoscope tutorial, you'll see how it's done around chapter seven or eight. – arnt Feb 13 '21 at 14:56
  • I've looked through the tutorial but I'll look again for what you mean - but are you suggesting that I can capture the output of the JIT and execute it as needed? – muke Feb 13 '21 at 15:46
  • 1
    Yes. The JIT writes output and you provide it with a place to write to, a place that you manage. There is no use-by date on the generated output. (Most JITs actually cache the generated output and use it n times, without knowing the precise value of n in advance.) – arnt Feb 13 '21 at 16:16
  • Oh, fair enough then, thanks for clearing this up. I saw there's a ORC JIT as well as an MC JIT, with the ORC JIT supposedly being newer. Info in the LLVM-C header files though say it's interface is still unstable and subject to change, do you know how severe this is, and if sticking with the MC JIT limits me in any significant way? – muke Feb 13 '21 at 16:19
  • 1
    I wouldn't know. The general LLVM answer is to look at the number of commits to the newer subsystem in the past six or twelve months, and in particular to the header files, and estimate the likely future churn rate from that. Sometimes the newer system is taking over *very slowly*. – arnt Feb 13 '21 at 17:18

0 Answers0