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). The toolchain is still in a very early stage and likely has many issues, especially around corner cases.
git checkout release_38; mkdir build; cd build; cmake ..; make)README.md)
To compile a test.c C file with it for STM8:
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.ll filellvm-cbe/bin/llvm-cbe test.ll. This should give you a test.cbe.c file.sdcc -mstm8 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-libcalls since 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.
alloca())static inline functions even when all uses are inlined, resulting in larger-than-necessary code sizevolatile in the cbe