Compiler driver

Hi all,

I'm developing a custom back-end for an odd-ball architecture (but one that is still describable by LLVMTargetMachine). The toolchain that it will fit into doesn't have a linker as such, so I want to use assembly as the default output. I've got to the point of emitting working custom assembly for very simple C programs (i.e. ones that don't rely on libraries). At the moment, I'm doing this through clang-cc and llc:

  clang-cc -D=MY_ARCH -emit-llvm-bc -o - in.c \
  > llc -filetype=asm -march=my_arch

I want to be able to package this compiler as a cross-compiler - a single binary to go from C to assembly for that target. It should define a macro (as shown above) to allow the target to be identified by source code. I was thinking of doing this using llvmc to capture the above command-line. Is that the recommended approach?

Also, I don't want to rely on GLIBC. I want something like newlib (which is what we used successfully with our previous GCC back-end). How do I go about doing that with LLVM?

Any help is appreciated.

Regards,

- Mark

clang-cc does not longer exist, so you should not rely on it and use clang instead.

You should be able to use it exactly the same way that you was using gcc (it is designed to be a drop in replacement), so "clang -arch my_arch -DMY_ARCH -S -o - in.c" should works.

-- Jean-Daniel

Thanks for the reply.

I can’t get clang to accept the architecture - it runs gcc instead. Maybe I’m doing something wrong when I modified LLVM to accept my architecture. I did the following:

  • Modified ‘configure’ to specify my architecture’s name in TARGETS_TO_BUILD.
  • When running configure, the --enable-targets=MY_ARCH option is given.
  • Added my architecture to the Triple::ArchType enumeration (in include/llvm/ADT/Triple.h).
  • Added suitable code to the switch statements that use Triple::ArchType (in lib/support/Tripple.cpp).

‘llc’ accepts my target. I’m building clang inside ‘tools/clang’ of the LLVM working copy, in accordance to the documentation. I see clang getting rebuilt every time I modify my target’s source files.

I should’ve mentioned that I’m working from the 2.6 release.

Also, once I’ve got that working, is there a way to make clang use these options by default? What’s the difference between ‘clang’ and a custom driver built using ‘llvmc’?

Regards,

  • Mark

Hi Mark,

Mark Muir <mark.i.r.muir <at> gmail.com> writes:

I want to be able to package this compiler as a cross-compiler
- a single binary to go from C to assembly for that target. It
should define a macro (as shown above) to allow the target to
be identified by source code. I was thinking of doing this
using llvmc to capture the above command-line. Is that the
recommended approach?

Yes, llvmc is probably what you need. It was successfully used to
create a driver for the PIC16 toolchain. Look at llvmc docs and
tools/llvmc/examples/mcc16, this should get you started. If you
have any further questions, mail me.

What's the difference between 'clang' and a custom driver built
using 'llvmc'?

The clang driver is developed separately from llvmc.

Hello, Everyone

What's the difference between 'clang' and a custom driver built
using 'llvmc'?

The clang driver is developed separately from llvmc.

Just to make things more clear: clang driver is intended to be
bug-per-bug compatible with gcc with all crazy different ways of
declaring options, redefining them, etc.

llvmc aims in providing "clean" compiler driver in the case when your
tools have more or less regular and sane option set and you just need
to schedule and driver them in proper direction. I believe using
llvmc2 for clang driver in theory is possible, but definitely does not
worth so.