I participates in a binary translation project which leverages
LLVM JIT capability. We have done x86 -> x86 translation, and
we would like to add more host target support. One potential
target is ARM. I am wondering if I can help LLVM make its ARM
JIT more well-formed.
I don't know what LLVM ARM JIT status in LLVM 2.8 and LLVM 2.9
release is. My idea is making LLVM ARM JIT well-formed in current
First, I have to choose the most bug-free GCC and toolchain to
compile LLVM for ARM. I am not sure if the link  is up to date
or not. But according to Karel's work , GCC 4.3.4, 4.4.1 are
the best one I have. Then, as what Karel did, I am planing to
examine what revision failed to pass `make check`. But I don't
think `make check` can catch all ARM backend flaws, especially
ARM JIT flaws, which is I most care about. Since compiling LLVM on
ARM *natively* is time-consuming, I'll cross compile LLVM for
ARM first. But I do have some concerns here.
1. I am not sure if there are enough people who have interest
in making LLVM ARM support a good shape. My post  about
rev. 131463's issue seems to be ignored.
2. Karel claimed GCC 4.3.4, 4.4.1, ... etc, can be the reference
GCC used to compile LLVM for ARM. The conclusion is based on
the result of `make check`. What do you think about this
conclusion? Because the bad thing is if we use a broken GCC
(do compile LLVM, but generate the WRONG code), it's hard to
tell which side should be blamed.
3. As I said above, I'll plan to cross compile LLVM for ARM
first, so that I can spot what revision cause the failure
quickly. But I don't know if this is O.K.. I use crosstool-ng
to build the cross toolchain, by the way. According to my
experience, the cross compiler which is more similar to
the native one, i.e. has same --with-arch, --with-tune, ...etc,
might trigger *more* failure than the native one does. The cross
compiler built with default options has the same `make check`
result as the native one, which is strange to me.
Any comments, suggestions are welcomed.