[LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha

[Chris Lattner]

Hi Zack, welcome!

On Mar 13, 2009, at 5:41 PM, Zack Weinberg wrote:
> 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"
> 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