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
Le 16 déc. 2009 à 10:54, Mark Muir a écrit :> 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?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 On 16 Dec 2009, at 11:49, Jean-Daniel Dupas wrote:> > Le 16 déc. 2009 à 10:54, Mark Muir a écrit : > >> 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? > > 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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091216/ab4172af/attachment.html>
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. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University