The LLVM+SDCC toolchain is meant to allow the use of languages other than C and to evaluate the effect of LLVM optimizations for 8-bit targets. Currently, it consists of a fork of the LLVM C frontend (cfe) clang, the LLVM optimizer (optional), the LLVM C backend (cbe; no longer part of LLVM, now maintained independently from LLVM). and the Small Device C Compiler (SDCC). he toolchain is still in a very early stage and likely has many issues, especially around corner cases.
Installing the LLVM+SDCC toolchain
Install SDCC (recommended version: 3.6.3 #9784 or later, but earlier version will mostly rok as well)
Install LLVM 3.8 (e.g. using apt-get on Debian).
Get the cfe forkand build it (e.g. mkdir build; cmake ..; make)
Get the cbe fork (as of 2016-10-11 you should use the standalone branch)and build it (see instructions in README.md)
Using the LLVM+SDCC toolchain
To compile a test.cC file with it for STM8:
Compile C source to LLVM IR: clang/build/bin/clang -fno-signed-char -target sdcc-stm8 -S -emit-llvm -isystem /usr/local/share/sdcc/include test.c(you might want to change the include path depending on where your SDCC header files are installed). This should give you a test.llfile
Compile LLVM IR to C: llvm-cbe/bin/llvm-cbe test.ll. This should give you a test.cbe.cfile.
Compile to binary: sdcc -msmt8 test.cbe.c.
The above process should result in a working binary file just as if the original C file had been compiled with SDCC directly. However the binary will probably be less optimized as SDCC is not yet able to optimize out all the overhead generated in the translations. But if you optimize the LLVM IR before converting it to C, you might well get a more optimized result than with plain SDCC. To optimize, use e.g. opt-3.8 -O2 -disable-simplify-libcalls -S(we need -disable-simplify-libcallssince for opt-3.8, sdcc-stm8 is an unknown target triple, so it assumes the host architecture; this breaks the simplification of libcalls, since e.g. some printf() calls get converted to putchar(), but we get a putchar() that takes a 32-bit int; this would result in stack corruption later).
The files compiled using the above process can be freely linked with files compiled using SDCC directly.
No support for SDCC extensions in the cfe
Probably different compiler-defined behaviour in some corner cases
No support for some features that are not supported by SDCC (most prominently variable-length arrays and alloca())
Currently only stm8, z80, z180, gbz80, r2k, r3ka, tlcs90 SDCC backends supported
Support for languages other than C is untested
Floating-point support is untested
SDCC emits function definitions for static inlinefunctions even when all uses are inlines, resulting in larger-than-necessary code size
There is a bugin the handling of volatilein the cbe