Hi Zack, welcome!
I'm trying to persuade llvm (svn trunk) to build in a mode where it
*runs on* amd64 but *generates code* for alpha, exclusively. (Well,
technically, generate code for my experimental architecture simulator
that happens to be based on alpha.) I have been unable to find any
combination of configure switches that makes this happen. I should
probably underline that I am _not_ trying to cross-compile LLVM, I am
trying to make LLVM _be_ a cross compiler.
Ok. I'm not sure how much of this was clarified by follow up posts, but I'll try to help.
- The "natural" way to do that (by which I mean "the way you would do
it if you believe what it says in the autoconf manual") would be to
specify --build=x86_64-unknown-linux --target=alpha-unknown-linux.
This produces Makefiles that bomb out on the very first file in the
tree:
$ make
llvm[1]: Compiling Alarm.cpp for Debug build
cc1plus: error: unrecognized command line option "-mieee"
because Makefile.config has ARCH=Alpha, and Makefile.rules changes the
options passed to the build compiler based on ARCH. IMO this is a
bug, but I don't understand your makefile system well enough to fix
it.
LLVM and Clang (but not llvm-gcc) use a different approach than the standard autoconf model for building cross tool chains. Instead of configuring the build to specialize it for one target, we just set the list of enabled targets. LLVM is natively cross build aware and the tools can all support multiple targets at once (even dynamically loading them).
To pick a set of targets to build, configure llvm with the --enable-targets=foo option, where foo is "all" (the default) "native" (host target only) or a list of llvm targets to build. This is strictly an optimization to reduce build time of llvm, you should always be safe to just build all targets.
- The other obvious thing to try is not giving any --build or
--target options but instead --enable-targets=alpha. This builds
successfully but produces llvmc and clang binaries that generate code
for x86_64 by default, and spit out a "unrecognized architecture"
error if I give -arch=alpha.
Some random tidbits of advise:
llvmc is still in early development, and I'm not sure what its support for cross-builds are.
The Alpha target (afaik) generally works, but is considered experimental. Andrew L can answer any specific questions about its state.
Clang is under active development, but the C/ObjC compiler is very usable on x86 32/64. The Clang driver OTOH is still under active development, I'd expect it to settle down in the next couple weeks. When it is complete, the clang driver will fully support a couple of modes for doing a cross compile. First, just running "clang foo.c" will build for the native architecture. "clang foo.c -arch alpha" will build the same OS as the current, but target the alpha processor (e.g. linux/x86 -> linux/alpha). You can also fully specify a triple with "clang -triple=x-y-z foo.c".
I have some other, closely-related questions:
- I assume I need a cross-assembler and -linker. Will GNU binutils
in cross-architecture mode work for that?
Yes!
How do I persuade it to use
them? It seems to be setting itself up to feed Alpha code to "as"
instead of "<target-triplet>-as" which isn't going to work.
I don't know, Daniel should be able to help with this. I assume that the new clang driver will be able to handle this somehow. 
- Does clang have the necessary code to support Alpha? I noticed
some very architecture-specific-looking code in there, to do with
calling conventions; I'm basically going to have to write that from
scratch for my modified architecture anyway but it would be nice to
know for sure whether it already had the baseline support. (I'm
avoiding llvm-gcc because I know from extensive prior experience with
GCC that it almost certainly cannot handle the semantics of my
modifications at all.)
Unfortunately, no we don't support alpha in clang yet. The required code (which goes in lib/Basic/Targets.cpp) is twofold: you have to specify the size of the alpha datatypes and alpha predefined macros, and 2) you have to do some calling convention work for lowering.
The second is pretty nasty, but is only needed if you need something fully abi compliant with your host compiler. If you're just using scalars like floats/ints/pointer, you should be ok without doing any of this work. For example calling into libc/libm and other simple libraries like that should generally work. This may be enough for your research purposes. If you have more detailed questions about Clang specifically, I'd recommend emailing the cfe-dev mailing list.
-Chris
