Hello again,
I'm exploring llvm's intermediary representation with this code:
////////////////////////////////////
%.LC0 = internal constant [13 x sbyte] c"hello world\0A\00"
declare int %puts(sbyte*)
implementation
int %main() {
%cast210 = getelementptr [13 x sbyte]* %.LC0, long 0, long 0;
call int %puts(sbyte* %cast210)
ret int 0
}
////////////////////////////////////
And I can compile and run it like this:
llvm-as foo.ll
lli foo.bc
or
llvm-ld foo.bc -o foo
Which prints "hello world". This is great, but I can't figure out where the "puts" function is coming from. Does lli and llvm-ld automatically export the c standard library to the input file?
Second, it looks like I cannot specify an alternative runtime for lli. I'm guessing I'd have to build my own interpreter/jit if I want to run with a custom runtime. It looks like llvm-ld can accept libraries though, so I may be able to pass in the runtime there. Is this correct?
Thanks,
-e
Hi Erick,
Hello again,
I'm exploring llvm's intermediary representation with this code:
////////////////////////////////////
%.LC0 = internal constant [13 x sbyte] c"hello world\0A\00"
declare int %puts(sbyte*)
implementation
int %main() {
%cast210 = getelementptr [13 x sbyte]* %.LC0, long 0, long 0;
call int %puts(sbyte* %cast210)
ret int 0
}
////////////////////////////////////
And I can compile and run it like this:
llvm-as foo.ll
lli foo.bc
or
llvm-ld foo.bc -o foo
Which prints "hello world". This is great, but I can't figure out where
the "puts" function is coming from. Does lli and llvm-ld automatically
export the c standard library to the input file?
lli incorporates libc and when it goes looking for "puts", it finds it
and links to it.
llvm-ld just builds an executable with unresolved references to puts
which are then dynamically resolved at runtime.
Second, it looks like I cannot specify an alternative runtime for lli.
I'm guessing I'd have to build my own interpreter/jit if I want to run
with a custom runtime.
Right.
It looks like llvm-ld can accept libraries
though, so I may be able to pass in the runtime there. Is this correct?
Perhaps. Please note that llvm-ld is experimental at this point. Its
support for generation of native libraries and executables is weak. It
will handle bytecode fine but doesn't know what to do with native
libraries. Your best bet is to just compile your runtime into bytecode
and link it in. That way, only the portion of your runtime a program
actually uses is linked in and your runtime benefits from
inter-procedural optimization with your program.