Make LLVM ARM JIT well-formed

Hi, all

  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
LLVM svn.

  First, I have to choose the most bug-free GCC and toolchain to
compile LLVM for ARM. I am not sure if the link [1] is up to date
or not. But according to Karel's work [2], 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 [3] 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.

Regards,
chenwj

[1] http://llvm.org/docs/GettingStarted.html#brokengcc
[2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041214.html
[3] http://comments.gmane.org/gmane.comp.compilers.llvm.devel/42084

Hi Chenwj,

The main problem is that the ARM JIT doesn't currently use the MC architecture. There is work ongoing to convert it to use MC, but that is not moving very fast and any work done in the meantime on the current architecture will be thrown away when MC hits - this makes it less worthwhile to try and get the current ARM JIT in decent shape.

If active work starts on the MC conversion I'd be happy to help out myself.

James

Hi, James

The main problem is that the ARM JIT doesn't currently use the MC architecture. There is work ongoing to convert it to use MC, but that is not moving very fast and any work done in the meantime on the current architecture will be thrown away when MC hits - this makes it less worthwhile to try and get the current ARM JIT in decent shape.

If active work starts on the MC conversion I'd be happy to help out myself.

  I don't know if the MC conversion will be ready on LLVM 3.0 release,
and what ARM JIT's status is at that time. So we use LLVM 2.8 currently
to jit arm code. LLVM 2.8 might be old, but LLVM 2.9 seems worse based
our experience. The problem of LLVM 2.9 we encounter is the LLVM IR
generated pass the verifier, but it can be jitted.

Regards,
chenwj