As of the writing of this note, the llvmc tool is enabled for build on
the CVS head. I'm encouraging you to try it out, provide some feedback,
and help with the issues below.
llvmc is now able to correctly link a pure bytecode version of any
Stacker program. This includes translation with stkrc, optimization with
opt and linking with llvm-link. It is also able to find Stacker's
runtime library automatically using the "dependent libraries" feature of
the VMCore IR. For example:
bash-2.05$ llvmc fibonacci.st -o fibo -f -v
stkrc -s 2048 fibonacci.st -o /tmp/llvm_1zyB4x/fibonacci.st.trans -f
opt /tmp/llvm_1zyB4x/fibonacci.st.trans -o /tmp/llvm_1zyB4x/fibonacci.st.opt -simplifycfg -instcombine -mem2reg -f
llvm-link /tmp/llvm_1zyB4x/fibonacci.st.opt /proj/work/llvm/cfrontend/install/bytecode-libs/stkr_runtime.bc -v -f -o fibo
Linking in '/proj/work/llvm/cfrontend/install/bytecode-libs/stkr_runtime.bc'
Note that without any -L option to llvmc or any mention of
"stkr_runtime.bc", llvmc was able to find and link the Stacker runtime
llvmc is now also *mostly* compatible with GCC's compiler driver. For
example, here's an attempt to use llvmc as the CXX variable when
building the CompilerDriver.cpp file (part of llvmc):
bash-2.05b$ gmake VERB= CXX=llvmc
/proj/work/llvm/build/mklib --tag=disable-shared --silent --tag=CXX \
--mode=compile llvmc -c -I/proj/work/llvm/build/tools/llvmc \
-I/proj/work/llvm/build/../llvm/tools/llvmc -I/proj/work/llvm/build/include \
-I/proj/work/llvm/build/../llvm/include -I../../include \
-I/proj/work/llvm/build/../llvm/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS \
-DATTR_DEPRECATED='__attribute__ ((deprecated))' -Wall -W -Wwrite-strings \
-Wno-unused -g -D_DEBUG \
/proj/work/llvm/build/../llvm/tools/llvmc/CompilerDriver.cpp -o \
Unknown command line argument '-DATTR_DEPRECATED=__attribute__ ((deprecated))'. Try: 'llvmc --help'
Unknown command line argument '-fPIC'. Try: 'llvmc --help'
gmake: *** [/proj/work/llvm/build/tools/llvmc/Debug/CompilerDriver.lo] Error 1
Unfortunately, -fPIC is out of scope for llvmc and the CommandLine.h
parser for strings doesn't like the = or space in the -D option.
Some unresolved issues that I would appreciate feedback on:
1. How important is 100% compatibility with GCC? (my take: "not very",
but we should be "close" where it makes sense).
2. Can the -D problem shown above be solved without modification to
the CommandLine library? Note that other -D options were accepted by
3. Should -fXXX options just be passed through to compiler tools? Or,
should they be accepted and ignored, or should they be reported as
errors as shown above?
4. What exactly should happen for native code linking? Should gccld be
used in conjunction with llc? Should I use a native linker? Should
linking be specifiable in the configuration? If so, how? Its not
5. What do we do if a "dependent library" specifies a name and the first
thing found is a native library but the llvmc command line isn't
building a native executable? Should the dependent library just be
passed through to llvm-link so that the interpreter/jit can
dynamically load it at run time? How can we ensure that there are
no unresolved symbols in this case? Should a native link also
produce a bytecode "stub" that contains declarations of the things
in the native library?
All thoughts appreciated.