LLVM on ARM testing.

Hello,

I asked here for kind of reference GCC version which LLVM development team is using for *native* testing on ARM hardware. (no cross compilation!) last week or so. I've been curious myself how the situation looks and so I tested LLVM 2.9 as a reference point and LLVM HEAD as of June 29 on ARMv7 (two boards with two different Ubuntu versions) compiled by GCC 4.3.4, 4.4.1, 4.4.5, 4.5.2, 4.6.1 Linaro 2011.05 and 4.6.1 Linaro 2011.06. It looks like LLVM HEAD does have about 28 regressions in comparison with LLVM 2.9. If you are curious to know more or to get actual `make check' logs for all the combinations please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/

Is there anything other I might do for you to get those regressions fixed?

Thanks,
Karel

I just filed http://llvm.org/bugs/show_bug.cgi?id=10258 for the
2009-06-05-VariableIndexInsert.ll failure.

For the JIT failures, it would be nice if you could track down the SVN
revision when it started failing. (We have an ARM buildbot at
http://google1.osuosl.org:8011/builders/clang-native-arm-cortex-a9 ,
but the JIT was already broken when it was set up.)

-Eli

Hi, Karel

  Do you have any plan on figuring out since what svn version
the ARM JIT had been broken?

Regards,
chenwj

I'll try binary search between May 26 (1st build of buildbot) and April 6 (2.9 release) and will see if I get to something.

Thanks,
Karel

Hi Karel,

This is great!

I can see there's only a handful of errors. All JIT errors seem to be
the same (MC). All O2 errors, too (MIPS). The select.ll error was
fixed by Eli last month, so not to worry.

Do we have a similar thing for x86? Just to make sure the Mips errors
are not ARM specific.

About your configure options, I have some questions:

- You use "--with-arch=armv6 --with-tune=cortex-a8", shouldn't it be armv7?

- You're using softfp on Cortex-A8, have you tried with VFPv3/NEON?

- On GCC 4.4.5 you're using "--with-float=softfp --with-fpu=vfpv3-d16"
and (correctly) "--with-arch=armv7-a", which mode prevails? Soft or
hard?

- You're using Thumb on 4.4.5 and 4.5.2 only, any special reason not
to use Thumb on previous GCCs?

cheers,
--renato

I've used my i.MX53 board to get this, but I'm returning it today back to Freescale and my pandaboard is testing GHC performance so I'll not be able to get to this again earlier than next week.

Anyway, JIT failures happens somewhere between 131458 (which is OK) and 131466 (where JIT tests fail). Let me know if this is enough or I shall continue to point to the culprit revision directly.

Thanks,
Karel

Hi Renato,

please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/

Is there anything other I might do for you to get those regressions fixed?

Hi Karel,

This is great!

I can see there's only a handful of errors. All JIT errors seem to be
the same (MC). All O2 errors, too (MIPS). The select.ll error was
fixed by Eli last month, so not to worry.

W.r.t select.ll error, I'm not sure it is really fixed. I'll need to retest I'm using here few days old HEAD so it'll be quick.

Do we have a similar thing for x86? Just to make sure the Mips errors
are not ARM specific.

I'm not sure, I don't test on x86, but my general feeling about LLVM-2.9 on x86 and ARM, was that x86 was in better shape -- that was a time I tested on x86...

About your configure options, I have some questions:

- You use "--with-arch=armv6 --with-tune=cortex-a8", shouldn't it be armv7?

- You're using softfp on Cortex-A8, have you tried with VFPv3/NEON?

- On GCC 4.4.5 you're using "--with-float=softfp --with-fpu=vfpv3-d16"
and (correctly) "--with-arch=armv7-a", which mode prevails? Soft or
hard?

- You're using Thumb on 4.4.5 and 4.5.2 only, any special reason not
to use Thumb on previous GCCs?

All the questions above are answered with simple answer: I'm using system (i.e. ubuntu) provided GCC (except linaro) and so the params are those Ubuntu package maintaners used. On linaro I'm using ARM mode based on the experience with 4.4.1 which also uses ARM mode and looks better than 4.4.3/4.5.2 which are using thumb by default.

No, I've not tried to use VFPv3/NEON yet.

Cheers,
Karel

I'm not sure, I don't test on x86, but my general feeling about LLVM-2.9
on x86 and ARM, was that x86 was in better shape -- that was a time I
tested on x86...

Unfortunately, that's how it is. This is why your tests are so important.

All the questions above are answered with simple answer: I'm using
system (i.e. ubuntu) provided GCC (except linaro) and so the params are
those Ubuntu package maintaners used. On linaro I'm using ARM mode based
on the experience with 4.4.1 which also uses ARM mode and looks better
than 4.4.3/4.5.2 which are using thumb by default.

I see. You seem not to be hitting any execution error, so that's secondary.

No, I've not tried to use VFPv3/NEON yet.

You probably are, not intentionally. Some of your compilation options
demanded VFPv3, so it should generate some of it (at least a few
VMOVs). Again, that's secondary.

thanks,
--renato

Given that revision range, the only remotely likely culprit is 131463.
Which basically means that it "broke" because the default target
features changed.

I'll going to try and debug this.

-Eli

Pandaboard's finished testing a little bit sooner so it's now on tracking job again. 131462 was OK, now testing 131464...

Karel

And you are right here. 131463 == 131464 which is buggy. 131462 is OK.

Thanks,
Karel

Mmm... and I just realized I really can't help track this down because
the code paths in question are probably Linux-specific. I spent a
little time talking to Jim, and there's probably just a few
instructions that need straightforward fixes; someone just needs to
put lli under a debugger, see which instructions are unimplemented
and/or broken, and implement/fix them.

-Eli

Hi, Eli

Mmm... and I just realized I really can't help track this down because
the code paths in question are probably Linux-specific. I spent a

  I add the following line back to lib/Support/Unix/Host.inc,

Arch = "arm";

  And examples/HowToUseJIT works fine.

Regards,
chenwj

[1] http://llvm.org/viewvc/llvm-project?view=rev&revision=131463

  I add the following line back to lib/Support/Unix/Host.inc,

Arch = "arm";

  And examples/HowToUseJIT works fine.

  I compile LLVM r131463 (which is the culprit claimed by Karel)
with Ubuntu gcc 4.4.1. Attach is the `make check` log.

Regards,
chenwj

llvm-131463-gcc-4.4.1.log (2.98 KB)

Hi, Eli

  The attach is the result of `make check` of TOT (r135745).

Regards,
chenwj

llvm-135745-gcc-4.4.1.log (6.11 KB)

I'm curious if anybody is still tracking the status of ARM support in
LLVM. Right now I'm getting the following errors for llvm-3.0rc4 test
suite on arm linux system:

Hi,

Most of those test failures are due to the JIT, which is unmaintained for
ARM and known to be dead. The only ones that worry me are the objdump ones,
but llvm-objdump is still under development so it's not so surprising.

Cheers,

James

I'm curious if anybody is still tracking the status of ARM support in
LLVM. Right now I'm getting the following errors for llvm-3.0rc4 test
suite on arm linux system:

  I tracked the status of ARM support few months age. There is a discussion
thread before.

  ARM Qualification
  http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044026.html

I think it just needs someone to organize how the ARM testing is done and how
to track where the bug is.

Regards,
chenwj