llvm-ir | LLVM IR in natural Rust data structures | Compiler library

Never mind, i fixed it by installing clang/llvm 10, using WSL, sure, it's not the latest version, but it's better then nothing.

Is it a pointer to an empty struct ?

Yup. Somewhat like a void pointer. void* is not a valid type in LLVM IR, most frontends use i8* for this purpose.

What does this instruction do ?

It's an indirect call. That first {}* is the return type of the callee (and guaranteed to be a nonnull pointer at that!), the callee is the value i64 140019712366044 casted to pointer to function that returns {}* and takes two parameters, {}* and i64. Then for the first parameter, it passes this function i64 140019153768096 casted to {}* and 0 as the second parameter.

Those constant numbers suggest that this is a JIT and those are pointers to things outside this LLVM IR module.

On running your example using lli-10 I get a @printf' defined with type 'i32 (i8*, ...)*' but expected 'i32 (i8*, double)*' error rather than a successful call that prints 0.000000.

This error is expected, and the reason why is explained here. The relevant bit from the post is

... if the type in front of the call is a function pointer type, then that is used as the type of the thing being called, while if it's not, then it is used as the return type, and the type of the call is inferred from the arguments present on the instruction.

That is why LLVM infers printf's type in the first call as i32 (i8*, double)* but later finds out it's declared as i32 (i8*, ...)*. To fix this simply annotate the calls properly,

Based on this answer, I worked around this by passing -Z build-std to Cargo, thereby getting the LLVM IR from Rust's core library, and linking it in.

But then I realized I can do one better, and avoid the long compilation time imposed by -Z std, by just taking the definitions of core::panicking::panic_bounds_check and core::panicking::panic from these IR files, simplifying their body, and adding them to a hand-written panic.ll file:

Okay. So, answering here. As you see, you need to first get zero index, after than indexes 7 and 0. The reason is simple to explain. Let's see an example why extra zero is needed:

The missing ingredient was:

Looking at the source code of Module::getTypeByName, it looks up the name in the LLVMContext instance. This means you don't have to add your type to the module and name lookup should work just fine, even through a Module instance.

Your main problem looks to be that you're returning a pointer to alloca-allocated memory (i.e. local memory) from @va_start. You should either make it take a pointer as an argument like @llvm.va_start does or get rid of the function altogether and call @llvm.va_start directly from @println.

PS: I don't understand what the point of your %0 type is. If it's supposed to represent an argument list, why not use i8* (which is what the LLVM vararg functions expect) directly instead of bitcasting it.

PPS: The format string and number of arguments in your source code doesn't match those in your generated LLVM. I'm guessing the LLVM was actually generated from a different source code (specifically println("Hello World %i?", 1)).

You can generate llvm-ir for your static library using clang++. Then link that with your compiler's output (i.e the llvm-ir from which you intend to call the library functions) using llvm-link. And you've got your final ir.