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
--
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667
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> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of ??? > Sent: 04 August 2011 04:37 > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] 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 > > -- > Wei-Ren Chen (陳韋任) > Computer Systems Lab, Institute of Information Science, > Academia Sinica, Taiwan (R.O.C.) > Tel:886-2-2788-3799 #1667 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667