[LLVMdev] llvmc - Compiler Driver - Status Update & Issues

[Reid Spencer]

Folks,

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
Loading '/tmp/llvm_1zyB4x/fibonacci.st.opt'
Loading '/proj/work/llvm/cfrontend/install/bytecode-libs/stkr_runtime.bc'
Linking in '/proj/work/llvm/cfrontend/install/bytecode-libs/stkr_runtime.bc'
Writing bytecode...

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
library. 

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$ pwd
/proj/work/llvm/build/tools/llvmc
bash-2.05b$ gmake VERB= CXX=llvmc
Compiling CompilerDriver.cpp
/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 \
  /proj/work/llvm/build/tools/llvmc/Debug/CompilerDriver.lo
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
    llvmc.
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
    language specific.
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.

Thanks,

Reid.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040829/57b7dafd/attachment.sig>