Zack Weinberg
2009-Mar-14 00:41 UTC
[LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha
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. - 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. - 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. 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? 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. - 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.) Thanks, zw
Bill Wendling
2009-Mar-14 01:09 UTC
[LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha
Hi Zack, On Fri, Mar 13, 2009 at 4:41 PM, Zack Weinberg <zackw at panix.com> 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. > > - 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 has different back-ends that it generates. These back-ends are loaded when needed. You select them with the "-march" option of the "llc" tool. What you're trying to do here is have the LLVM *binaries* be Alpha binaries. That won't work for you. For instance, the compiler you're using to compile LLVM doesn't appear to support generating Alpha binaries.> - 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. >llvmc will wrap around the llvm-gcc executable. If your built llvm-gcc doesn't allow the "-arch" flag, then that would be the reason. I don't think that the shipped llvm-gcc supports Alpha. I don't use "llvmc", though, so I'm not sure how to help you with this.> 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? 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.You are going to have to build llvm-gcc as a cross-compiler so that you can get the features you are wanting here. By default, llvm-gcc is built for the host platform, so there are no need for such <target-triplet> drivers. -bw> - 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.) >
Zack Weinberg
2009-Mar-14 01:20 UTC
[LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha
On Fri, Mar 13, 2009 at 6:09 PM, Bill Wendling <isanbard at gmail.com> wrote:> On Fri, Mar 13, 2009 at 4:41 PM, Zack Weinberg <zackw at panix.com> 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....>> - 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 has different back-ends that it generates. These back-ends are > loaded when needed. You select them with the "-march" option of the > "llc" tool. What you're trying to do here is have the LLVM *binaries* > be Alpha binaries.That does appear to be what the makefiles are doing, but that is not what I want and not what --target is supposed to do; to "have the LLVM *binaries* be Alpha binaries" I ought to say --build=amd64-linux --host=alpha-linux and leave --target alone. Specifying --build and --target but not --host [again, according to the autoconf manual] is supposed to create binaries that run on the --build machine and generate code for the --target machine, which is what I want.> llvmc will wrap around the llvm-gcc executable. If your built llvm-gcc > doesn't allow the "-arch" flag, then that would be the reason. I don't > think that the shipped llvm-gcc supports Alpha. I don't use "llvmc", > though, so I'm not sure how to help you with this.I don't understand this. I am not using llvm-gcc and did not even install it.> You are going to have to build llvm-gcc as a cross-compiler so that > you can get the features you are wanting here. By default, llvm-gcc is > built for the host platform, so there are no need for such > <target-triplet> drivers.Same observation ... zw
Zack Weinberg
2009-Mar-14 02:07 UTC
[LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha
On reflection, the target architecture does not have to be Alpha. My actual requirements for the 'base' architecture are 64-bit pointers and no hardware stack. Is there a better-supported target architecture with those characteristics? zw
Mike Stump
2009-Mar-14 04:11 UTC
[LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha
On Mar 13, 2009, at 5:41 PM, Zack Weinberg wrote:> - 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.That would be the correct way to do this, but, I suspect no one around here has put in any time to make that work. You can either roll up your sleeves or leave those out and build all targets, and then use the tool specific options to select a different target other than the default one (the one for your build machine).
Bob Wilson
2009-Mar-14 05:39 UTC
[LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha
The bigger picture here is that you don't need to do anything special to build LLVM as a cross compiler. If you just run configure for LLVM without any --target options, the default is to include all the backends. You can then select a particular backend at runtime. It is only when you build llvm-gcc, which I understand you aren't interested in right now, that you need to specify --target to configure.
Andrew Lenharth
2009-Mar-14 15:12 UTC
[LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha
On Fri, Mar 13, 2009 at 7:41 PM, Zack Weinberg <zackw at panix.com> 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.What you want is llvm-gcc to be a cross compiler. llvm can be compiled natively with no extra flags. To generate alpha assembly from a bytecode, you use llc -march=alpha llvm and llc depend on the system assembler so to get binaries you will need a cross platform linker and an alpha assembler.> - 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"LLVM should be compiled as is for your architecture. It will then be able to optimize and produce asm for any supported arch (i.e. it is naturally cross platform). What you are doing is telling the Makefiles you are building on an Alpha.> 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 is a cross compiler by default, ARCH is the host machine, not the target machine. The simplest thing by far is to have a linux alpha system you can compile code on (rr use M5 in full system simulation mode). (Note I haven't built llvm-gcc for a while on alpha, and last I knew it died in libgcc on some of the math routines, but you can use the native compiler for those. The llvm-gcc executable works). Andrew
Chris Lattner
2009-Mar-16 18:25 UTC
[LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha
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
Misha Brukman
2009-Mar-16 19:03 UTC
[LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha
On Fri, Mar 13, 2009 at 8:41 PM, Zack Weinberg <zackw at panix.com> wrote:> - I assume I need a cross-assembler and -linker. Will GNU binutils > in cross-architecture mode work for that? 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.You'll need to configure llvm-gcc with these flags: --with-as=[path-to-your-as] --with-ld=[path-to-your-ld] You'll also need to have system headers for your target platform ready and specify them in --with-sysroot=[path] when you're configuring llvm-gcc. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090316/1244fc61/attachment.html>
Zack Weinberg
2009-Mar-21 00:22 UTC
[LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha
On Mon, Mar 16, 2009 at 11:25 AM, Chris Lattner <clattner at apple.com> wrote:> Hi Zack, welcome!I regret to say I'm disappearing again. I was only looking at LLVM for a class project which is now done with, and I'm not really interested in compiler development for the fun of it anymore. I do want to respond to some of the things that you (and others) said...> 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.As a general note, if you're trying to do cross compilation work, it is important to be able to set the compiler's *default* target architecture. "Oh, you can just build with support for all targets and then stick -arch=foobar on the command line" is not good enough, because setting up a cross compilation environment involves mucking with a good half-dozen different programs and libraries, none of which are configured in the same way -- oh, sure, you *can* hack up all their build systems to pass an extra switch to the compiler, but you really don't want to have to.>> 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.I don't like this answer. ;-) It is really really important for everything that has a "configure" script to support the baseline set of options defined by Autoconf, *with the semantics described in the Autoconf manual*. It's nice that LLVM can support more than one target per configuration, but that doesn't excuse not making --target do something sensible. (Per what I said above, how about having --target just set the default target, and if you want to prune the list there's still --enable-targets?) What --target presently does just makes no sense at all. I'd also like to mention that, on a one-year-old IBM laptop, building all the LLVM back-ends takes about three times as long as just building one of them. -- I don't mean to be ragging on y'all, but the fact is that I gave up on LLVM and went back to GCC for my project because of these build problems. I don't know if it would have been easier to make the modifications to LLVM that I had in mind than the modifications I ended up making to GCC -- but I didn't waste nearly a week trying to get a working cross toolchain with GCC. zw
Possibly Parallel Threads
- [LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha
- [LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha
- [LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha
- [Bug 32855] New: Incorrect image stretching with Render in RepeatPad mode, NV50
- [Bug 91705] New: [NVE7] GPU crash (read fault) on boot w/ DMI+HDMI outputs