On 2011-04-08 08:58, Duncan Sands wrote:> Hi Renato, > >> I was recently investigating the build bot infrastructure and noticed >> that the arm-linux target is failing for quite a long time. I believe >> that it means ARM code is not executed all that often in LLVM tests, >> is that correct?Hi i will summarise the last sucessfull builds by the ARM builder: http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/754 - Revision: 128836 last successful ARM build by the builder http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/755 - Revision: 128851 failed build http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/756 - Revision: 128873 failed 2010-11-04-bigbyval.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/756/steps/test-llvm/logs/2010-11-04-bigbyval.ll> ... 757 - 759 - dito http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/760 - Revision: 128895 failed 2009-03-17-lsr-apint.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/760/steps/test-llvm/logs/2009-03-17-lsr-apint.ll> add-with-overflow-128.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/760/steps/test-llvm/logs/add-with-overflow-128.ll> i128-addsub.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/760/steps/test-llvm/logs/i128-addsub.ll> ... 761 - 769 - dito http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/770 - Revision: 129068 failed build http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/771 - Revision: 129072 failed 2009-03-17-lsr-apint.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/771/steps/test-llvm/logs/2009-03-17-lsr-apint.ll> add-with-overflow-128.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/771/steps/test-llvm/logs/add-with-overflow-128.ll> i128-addsub.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/771/steps/test-llvm/logs/i128-addsub.ll> ... 772 - now - dito>> We were wondering what kind of support we could give to make sure ARM >> code is correct and don't regress, specially before releases (I know >> it's a bit late for 2.9).LLVM 2.9 was forked off the trunk at Revision 127228 so the above regressions are not in LLVM 2.9. unfortunally a fold-pcmpeqd-0.ll regression got into the 2.9 fork. http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/588 - Revision: 127193 last known successful ARM build by the builder before the 2.9 fork. http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/589 - Revision: 127214 failed fold-pcmpeqd-0.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/589/steps/test-llvm/logs/fold-pcmpeqd-0.ll> http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/590 - Revision: 127220 failed fold-pcmpeqd-0.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/590/steps/test-llvm/logs/fold-pcmpeqd-0.ll> *2.9 fork* - happened here http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/591 - Revision: 127237 failed fold-pcmpeqd-0.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/591/steps/test-llvm/logs/fold-pcmpeqd-0.ll> ... 592 - 593 dito http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/594 - Revision: 127289 failed fold-pcmpeqd-0.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/594/steps/test-llvm/logs/fold-pcmpeqd-0.ll> http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/595 - Revision: 127308 last known successful ARM build by the builder after the 2.9 fork. Hope this will help fix the regressions Cheers Xerxes>> We have thought about some routes: >> - Install some build slaves on our side, so you can test them (linux, >> bare-metal), if it's possible to cross-compile on build slaves. > there are several idle ARM buildslaves. There are the following slaves: > > gcc35: # 1TB 0.8 GHz Freescale i.MX515 (ARM Cortex-A8) / 512 MB RAM > / Efika MX Client Dev Board > > gcc50: # 250G 0.6 GHz ARM XScale-80219 / 512 MB RAM / Thecus N2100 NAS > > gcc55: # 250G 1.2 GHz ARM Feroceon 88FR131 (kirkwood) / 512 MB RAM / > Marvell SheevaPlug > > gcc56: # 320G 1.2 GHz ARM Feroceon 88FR131 (kirkwood) / 512 MB RAM / > Marvell SheevaPlug > > gcc57: # 320G 1.2 GHz ARM Feroceon 88FR131 (kirkwood) / 512 MB RAM / > Marvell SheevaPlug > > I can give you access to these machines if you like (send me your public ssh > key). > > Ciao, Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110408/200a6d91/attachment.html>
On 8 April 2011 11:21, Xerxes Rånby <xerxes at zafena.se> wrote:> Hope this will help fix the regressionsHi Xerxes, I see you're the owner of that board, thanks for the detailed description of the tests. By what you say, I think that the board itself is serving its purpose, and 2.9 only got that regression because it wasn't fixed it in time. My intention was to know what can we (ARM) can do to help LLVM repeat your success on all tests (clang, llvm, llvm-gcc, dragonegg), at least before each release. How can we make ARM a first-class target, in which a regression such as the one you found is a blocker to release. Duncan, I'm not sure me connecting to those boards will help much, since I know very little of the build-bot infrastructure. However, I'd be happy to help setting them up to run the tests we need (with some help in the beginning).>From what you've listed, we only have v5T and one cortex A8. We couldprovide more A8/A9s, M3s (mBed) boards and also models of all variations possible. Does it make any difference running them here at ARM or locally on OSUOSL? We could easily help them get more boards, too... On a different topic,>From what I understood, this tests run completely on the target(compilation of LLVM, unit tests, etc). So, for bare-metal tests that wouldn't work. We'd need to have a staging server that would compile to all platforms and run the tests (maybe just a subset) in the hardware via USB (mBeds) or JTAG on most other boards, or even better, on models directly. Do you think this is doable with the build bot infrastructure? cheers, --renato
Hi Renato,>I was recently investigating the build bot infrastructure and noticed >that the arm-linux target is failing for quite a long time. I believe >that it means ARM code is not executed all that often in LLVM tests, >is that correct?>We were wondering what kind of support we could give to make sure ARM >code is correct and don't regress, specially before releases (I know >it's a bit late for 2.9).>We have thought about some routes: > - Install some build slaves on our side, so you can test them (linux, >bare-metal), if it's possible to cross-compile on build slaves.It is possible. We host several build slaves which cross compile. The issue with cross compilation is that tests do support well the cross scenario. We are working on this but it moves slower then we wish it would be.>>From what you've listed, we only have v5T and one cortex A8. We could >provide more A8/A9s, M3s (mBed) boards and also models of all >variations possible.>Does it make any difference running them here at ARM or locally on >OSUOSL? We could easily help them get more boards, too...Llvm lab seems is the right place to put them, so people could get an access to boards for debugging. As a general note, my observations shows that slow builds gets less attention from the community then fast ones. This could be an issue with small boards. I have been tried native builds on a beagleboard, it took about 4 hours to build without the tests which is a bit too slow. We will need to find a way to make ARM builds faster. Thanks Galina On Fri, Apr 8, 2011 at 5:46 AM, Renato Golin <renato.golin at arm.com> wrote:> On 8 April 2011 11:21, Xerxes Rånby <xerxes at zafena.se> wrote: >> Hope this will help fix the regressions > > Hi Xerxes, > > I see you're the owner of that board, thanks for the detailed > description of the tests. > > By what you say, I think that the board itself is serving its purpose, > and 2.9 only got that regression because it wasn't fixed it in time. > > My intention was to know what can we (ARM) can do to help LLVM repeat > your success on all tests (clang, llvm, llvm-gcc, dragonegg), at least > before each release. How can we make ARM a first-class target, in > which a regression such as the one you found is a blocker to release. > > > Duncan, > > I'm not sure me connecting to those boards will help much, since I > know very little of the build-bot infrastructure. However, I'd be > happy to help setting them up to run the tests we need (with some help > in the beginning). > > >From what you've listed, we only have v5T and one cortex A8. We could > provide more A8/A9s, M3s (mBed) boards and also models of all > variations possible. > > Does it make any difference running them here at ARM or locally on > OSUOSL? We could easily help them get more boards, too... > > > On a different topic, > > >From what I understood, this tests run completely on the target > (compilation of LLVM, unit tests, etc). So, for bare-metal tests that > wouldn't work. We'd need to have a staging server that would compile > to all platforms and run the tests (maybe just a subset) in the > hardware via USB (mBeds) or JTAG on most other boards, or even better, > on models directly. > > Do you think this is doable with the build bot infrastructure? > > cheers, > --renato > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >