Hi all, 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. - Provide models or even hardware to whomever maintains the build slaves, to have a centralised infrastructure, if that's beneficial in any way. - Add linkage & execution to LIT tests, probably by using QEMU models, but that would create a dependence on QEMU for everyone. - Something else? As far as I could see, there is no current owner for the ARM tests (including linkage and execution). I'd like to get the ball rolling to better support testing and benchmarking the ARM code, with the ultimate goal of making sure it won't regress at least on every release, but hopefully for every patch. Could you please let me know what should I do, and what are the best ways of doing so? cheers, --renato
On Thu, Apr 7, 2011 at 7:38 AM, Renato Golin <renato.golin at arm.com> wrote:> Hi all, > > 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 Renato Not really apropos to your question specifically, but I have some downstream patches for ARM/MC/ELF/.o There were some issues that needs fixing. As soon as I get some time, I plan to upstream these patches in to trunk. Hopefully this should improve things a little bit... -jason> > 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. > - Provide models or even hardware to whomever maintains the build > slaves, to have a centralised infrastructure, if that's beneficial in > any way. > - Add linkage & execution to LIT tests, probably by using QEMU > models, but that would create a dependence on QEMU for everyone. > - Something else? > > As far as I could see, there is no current owner for the ARM tests > (including linkage and execution). > > I'd like to get the ball rolling to better support testing and > benchmarking the ARM code, with the ultimate goal of making sure it > won't regress at least on every release, but hopefully for every > patch. > > Could you please let me know what should I do, and what are the best > ways of doing so? > > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
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.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.
On 8 April 2011 07:58, Duncan Sands <baldrick at free.fr> wrote:> there are several idle ARM buildslaves. There are the following slaves:Hi Duncan, I could find them on the page http://google1.osuosl.org:8011/buildslaves but I couldn't tell they're ARM. Where do I get this list? Also, I believe they're testing llvm-gcc only (right?). The only target that was testing LLVM was the one failing, and no target is testing Clang. I'd like to have at least one each. To cover the minimum requirements, would be good to have {v5,v6,v7}x{linux,eabi}x{ARM,Thumb} where appropriate. I think the most important right now are at least one v5T, one A8 and one M3, on both linux (v5, A8) and bare-metal, testing on both ARM and Thumb(1 or 2) each. Is there a way to schedule different tests on the same boards, avoiding collision? Say, while LLVM test runs on A8 bare-metal, Clang tests run on linux and vice versa. cheers, --renato
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>