with the small patch attached below the whole llvm toolchain (llvm &
llvm-gcc) will compile and run under AMD64 Linux in native 64-bit LP64
mode.
Sounds great! I'll add it to the list of supported platforms.
This means that compilation, bytecode management and CWriter output
all work as expected. Of course there is no JIT, and the bytecode
interpreter is still very much untested - more patches may follow.
The bytecode interpreter is untested on many platforms -- part of the
reason is that it's very, very slow to run on reasonable programs.
If you want to work on something, getting LLC to produce AMD64 code
would be the first step, and getting the JIT to work would be the
second. I am assuming native 32-bit binaries will run, just slower, so
this is an "optimization". However, working on the interpreter is
largely a waste of your time.
The interpreter structure itself is due for a rewrite, see item #8 of
I believe x86 BE is due for "sub-target" support to handle variations in
the 386, 486, 586, ... instruction sets. Could amd64 be thought of this
way? Or, is it different enough that its a new target?
If by AMD64 you mean true 64-bit mode instruction set, I'd say it's different enough to warrant a new target. The differences between 386/486/586/etc are very minor in comparison.
If by AMD64 you mean true 64-bit mode instruction set, I'd say it's different enough to warrant a new target. The differences between 386/486/586/etc are very minor in comparison.
It depends on how different it is. It is quite similar to the differences between PPC32/PPC64 and Sparc V8/V9. Given this, it makes sense to support the target in lib/Target/X86, so that the common target description (which is most of it) can be shared between the 32 and 64-bit systems. As tblgen and the code generator in general improves, this will get easier and easier to implement.
By the way, I think that "X86-64" is more vendor neutral than AMD64, as intel supports effectively the same 64-bit extensions as AMD does. Given the choice, I think we should name subtargets, autoconf stuff, etc x86-64 instead of amd64.
However, working on the interpreter is