Admittedly we're very interested in becoming ARM backend maintainers as our product heavily relies on LLVM. However, we don't have testing resources to test both our product and LLVM on a host of target boards. We have some chumbys, beagleboards, iPhones, iPod Touches, tables, Android Phones, etc. And most of those are already booked solid with our own regression tests (most of which are based on llvm-test-suite) Could ARM enable us with testing hardware/resources? Thanks! Joe Abbey Software Architect Arxan Technologies, Inc. 1305 Cumberland Ave, Ste 215 West Lafayette, IN 47906 W: 765-889-4756 x2 C: 765-464-9893 jabbey at arxan.com<mailto:jabbey at arxan.com> www.arxan.com On Oct 13, 2011, at 12:48 PM, Renato Golin wrote: On 11 October 2011 18:22, Anton Korobeynikov <anton at korobeynikov.info<mailto:anton at korobeynikov.info>> wrote: 1. We should define which ARM-related features (in general, e.g. platforms, cores, modes, etc.) we consider "release important" 2. We should define the conditions how the features in 1. should be tested 3. Someone should perform such testing for each release, provide help with reproduction of the problems (consider e.g. PR11107, w/o Bill's help it would be extremely hard to reproduce the problem, since it manifests only on arm/darwin). 4. We should be able to guarantee that release-blocking bugs on ARM targets will be fixed (if technically possible) before the actual release. There is no point in define ARM as a release-blocking target if there is no commitment in actually fixing release bugs. What keeps ARM on the bench is just the lack of general commitment. Somebody has to own it, for real. cheers, --renato _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto: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/20111013/e41cf1bc/attachment.html>
I think we need a group of maintainers rather than a single maintainer given the spectrum of ARM targets/ISAs/platforms required to support and the amount of people/system resources required. I & my team plan to actively participate in the bug-fixing process during the release cycle. If we can divide the bugs among the maintainers and establish a requirement that all open ARM bugs must be fixed/addressed (at least analyzed if cannot be fixed) by release time, it will go a long way in ensuring high quality releases for ARM --Raja From: Joe Abbey [mailto:jabbey at arxan.com] Sent: Thursday, October 13, 2011 10:01 AM To: Renato Golin Cc: Anton Korobeynikov; rajav at codeaurora.org; James Molloy; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LLC ARM Backend maintainer Admittedly we're very interested in becoming ARM backend maintainers as our product heavily relies on LLVM. However, we don't have testing resources to test both our product and LLVM on a host of target boards. We have some chumbys, beagleboards, iPhones, iPod Touches, tables, Android Phones, etc. And most of those are already booked solid with our own regression tests (most of which are based on llvm-test-suite) Could ARM enable us with testing hardware/resources? Thanks! Joe Abbey Software Architect Arxan Technologies, Inc. 1305 Cumberland Ave, Ste 215 West Lafayette, IN 47906 W: 765-889-4756 x2 C: 765-464-9893 jabbey at arxan.com www.arxan.com On Oct 13, 2011, at 12:48 PM, Renato Golin wrote: On 11 October 2011 18:22, Anton Korobeynikov <anton at korobeynikov.info> wrote: 1. We should define which ARM-related features (in general, e.g. platforms, cores, modes, etc.) we consider "release important" 2. We should define the conditions how the features in 1. should be tested 3. Someone should perform such testing for each release, provide help with reproduction of the problems (consider e.g. PR11107, w/o Bill's help it would be extremely hard to reproduce the problem, since it manifests only on arm/darwin). 4. We should be able to guarantee that release-blocking bugs on ARM targets will be fixed (if technically possible) before the actual release. There is no point in define ARM as a release-blocking target if there is no commitment in actually fixing release bugs. What keeps ARM on the bench is just the lack of general commitment. Somebody has to own it, for real. cheers, --renato _______________________________________________ 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/20111013/91820329/attachment.html>
On Thu, Oct 13, 2011 at 10:00 AM, Joe Abbey <jabbey at arxan.com> wrote:> However, we don't have testing resources to test both our product and LLVM > on a host of target boards. We have some chumbys, beagleboards, iPhones, > iPod Touches, tables, Android Phones, etc. And most of those are already > booked solid with our own regression tests (most of which are based on > llvm-test-suite) > Could ARM enable us with testing hardware/resources?The ARM-based Raspberry Pi is very close to shipping. The entry-level unit will retail for just $25 with a higher-end model for $35. I don't recall who makes it, but there is an ARM desktop computer that retails for $149, with the same company making an ARM Netbook for $199. I have a Gumstix Overo Fire COM which I'm using mostly to experiment with ARM assembly code and ARM-specific optimizations in C, C++ and Objective-C. When I get it configured reliably I'd be happy to dedicate it as a test machine most of the time. https://www.gumstix.com/store/product_info.php?products_id=227 This has an ARM Cortex A8 with NEON SIMD as well as a Texas Instruments DSP. The DSP isn't programmed yet but could readily be with TI's DSP/BIOS and Code Composer Studio. I just spent days and days and days building all of Anstrom Linux for it, so it has a full GUI desktop environment, development tools and God Almighty Knows What Else installed on it. It is on my home LAN which has a dynamic IP, but I understand there is a way I can set up a tunnel to my web server which has a fixed IP. I can also ask my hosting service for an additional IP so if necessary I could tunnel ALL the ports to my Gumstix board. I also have a first-generation Apple iPhone which has iOS 3.0.6 installed on it. To use it for a testing bot I'd need to prevent it from ever going to sleep; I *think* I can do that by setting Auto-Lock to Never in the General section of the Settings App. I would need to package the tests as some kind of iPhone App which (maybe) I could load on the phone automatically by automating either iTunes or the iPhone Configuration Utility with AppleScript. I'm not sure what ARM CPU my first-gen iPhone has but I think it uses the arm6 instruction set. Finally I have three Oxford Semiconductor FireWire / USB / Parallel IDE storage bridge chip target boards. They all have ARM7TDMI cores with 64 kb to 128 kb of Flash and some microscopic amount of RAM: my OXFW911 chip has 64 kb of 16-bit Flash but only 1800 BYTES - not Megabytes, not Kilobytes, but just BYTES - of RAM. There wouldn't be enough memory in these things to run a shell, but any of the tests that could be packaged as a subroutine with a single entry point could be compiled into the firmware. These all run 16-but Thumb 1 and 32-bit ARM code. My iOS devices - I also have a first-gen iPad and an iPhone 4 - can run Thumb 2. If you'd like me to set these all up to do building and testing I'd be happy to, but I need some handholding. I've been trying to bootstrap llvm-gcc4.2 on Ubuntu 11.04 with the aim of using the CLang analyzer on ZooLIb (http://www.zoolib.org/) but the bootstrap always fails because of bizarre problems with autoconf's configure scripts. I've tried to debug the configure scripts but have yet to have any joy. IMHO autoconf is A Tool of the Devil. ZooLib is even more cross-platform than autoconf is, but does not need shell scripts at all to configure it. I need to catch some ZZZs now, I've been up all night. I'll have another go at configuring my Overo this evening, then will try bootstraping LLVM for x86 again. If that works then I'll bootstrap it for ARM as well. You can also run the tests in a emulator. The timing won't be accurate but you should be able to catch gross speed regressions. There are several emulators available; the ones I know about are Softgun, QEMU, the GNU Debugger GDB and the ARM Holdings development system emulator. There is another one that I came across once whose name I don't recall. Some emulators emulate a full computer with I/O devices so you can run an OS on them. These emulators could then host the build and not just the test. There are other simulators that just execute a single subroutine tree and provide standard input and output. The cool thing about this kind of emulator is that one can count the number of instructions required to go from the beginning to the end of the subroutine, or with the addition of a memory map that gives access times for various kinds of memory (16-bit Flash or Dynamic RAM) you can get cycle counts for the subrouine. The ARM Holdings emulator does this; I used it with great success to profile an Advanced Encryption Standard encryptor a while back. Ever Faithful, Don Quixote -- Don Quixote de la Mancha Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com quixote at dulcineatech.com
On Thu, Oct 13, 2011 at 10:33 AM, Raja Venkateswaran <rajav at codeaurora.org> wrote:> I think we need a group of maintainers rather than a single maintainer given > the spectrum of ARM targets/ISAs/platforms required to supportThere have been a plethora of ARM Instruction Set Architecture variants over the years. Which ones do we expect LLVM to support right now, and which as-yet unsupported ones do we wish to support? Am I correct that ARM7TDMI is the oldest, slowest core still in use? The Apple iPad 2 and iPhone 4S have the Apple A9 CPU, which I understand is a dual-core Cortex A9. The iPhone 4 and first-generation iPad have the Cortex A8. Xcode gives on the option of targeting either the arm6 or arm7 ISAs, with the recommended build being "Universal" in that the build is done twice with both ISA variants built into the same executable. I understand older iPhones and iPod Touches support the arm6 but not arm7. Ever Faithful, Don Quixote -- Don Quixote de la Mancha Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com quixote at dulcineatech.com
> The ARM Holdings emulator does this; I used it with great success to > profile an Advanced Encryption Standard encryptor a while back.It is indeed a useful piece of kit. We do a lot of our internal regression tests on it, and also run LLVM's regression tests every night on it (as well as PlumHall, EEMBC and SpecInt). Unfortunately it's not exactly software we can give away or give access to. ________________________________________ From: Don Quixote de la Mancha [quixote at dulcineatech.com] Sent: 13 October 2011 18:47 To: Joe Abbey Cc: Renato Golin; rajav at codeaurora.org; llvmdev at cs.uiuc.edu; James Molloy Subject: Re: [LLVMdev] LLC ARM Backend maintainer On Thu, Oct 13, 2011 at 10:00 AM, Joe Abbey <jabbey at arxan.com> wrote:> However, we don't have testing resources to test both our product and LLVM > on a host of target boards. We have some chumbys, beagleboards, iPhones, > iPod Touches, tables, Android Phones, etc. And most of those are already > booked solid with our own regression tests (most of which are based on > llvm-test-suite) > Could ARM enable us with testing hardware/resources?The ARM-based Raspberry Pi is very close to shipping. The entry-level unit will retail for just $25 with a higher-end model for $35. I don't recall who makes it, but there is an ARM desktop computer that retails for $149, with the same company making an ARM Netbook for $199. I have a Gumstix Overo Fire COM which I'm using mostly to experiment with ARM assembly code and ARM-specific optimizations in C, C++ and Objective-C. When I get it configured reliably I'd be happy to dedicate it as a test machine most of the time. https://www.gumstix.com/store/product_info.php?products_id=227 This has an ARM Cortex A8 with NEON SIMD as well as a Texas Instruments DSP. The DSP isn't programmed yet but could readily be with TI's DSP/BIOS and Code Composer Studio. I just spent days and days and days building all of Anstrom Linux for it, so it has a full GUI desktop environment, development tools and God Almighty Knows What Else installed on it. It is on my home LAN which has a dynamic IP, but I understand there is a way I can set up a tunnel to my web server which has a fixed IP. I can also ask my hosting service for an additional IP so if necessary I could tunnel ALL the ports to my Gumstix board. I also have a first-generation Apple iPhone which has iOS 3.0.6 installed on it. To use it for a testing bot I'd need to prevent it from ever going to sleep; I *think* I can do that by setting Auto-Lock to Never in the General section of the Settings App. I would need to package the tests as some kind of iPhone App which (maybe) I could load on the phone automatically by automating either iTunes or the iPhone Configuration Utility with AppleScript. I'm not sure what ARM CPU my first-gen iPhone has but I think it uses the arm6 instruction set. Finally I have three Oxford Semiconductor FireWire / USB / Parallel IDE storage bridge chip target boards. They all have ARM7TDMI cores with 64 kb to 128 kb of Flash and some microscopic amount of RAM: my OXFW911 chip has 64 kb of 16-bit Flash but only 1800 BYTES - not Megabytes, not Kilobytes, but just BYTES - of RAM. There wouldn't be enough memory in these things to run a shell, but any of the tests that could be packaged as a subroutine with a single entry point could be compiled into the firmware. These all run 16-but Thumb 1 and 32-bit ARM code. My iOS devices - I also have a first-gen iPad and an iPhone 4 - can run Thumb 2. If you'd like me to set these all up to do building and testing I'd be happy to, but I need some handholding. I've been trying to bootstrap llvm-gcc4.2 on Ubuntu 11.04 with the aim of using the CLang analyzer on ZooLIb (http://www.zoolib.org/) but the bootstrap always fails because of bizarre problems with autoconf's configure scripts. I've tried to debug the configure scripts but have yet to have any joy. IMHO autoconf is A Tool of the Devil. ZooLib is even more cross-platform than autoconf is, but does not need shell scripts at all to configure it. I need to catch some ZZZs now, I've been up all night. I'll have another go at configuring my Overo this evening, then will try bootstraping LLVM for x86 again. If that works then I'll bootstrap it for ARM as well. You can also run the tests in a emulator. The timing won't be accurate but you should be able to catch gross speed regressions. There are several emulators available; the ones I know about are Softgun, QEMU, the GNU Debugger GDB and the ARM Holdings development system emulator. There is another one that I came across once whose name I don't recall. Some emulators emulate a full computer with I/O devices so you can run an OS on them. These emulators could then host the build and not just the test. There are other simulators that just execute a single subroutine tree and provide standard input and output. The cool thing about this kind of emulator is that one can count the number of instructions required to go from the beginning to the end of the subroutine, or with the addition of a memory map that gives access times for various kinds of memory (16-bit Flash or Dynamic RAM) you can get cycle counts for the subrouine. The ARM Holdings emulator does this; I used it with great success to profile an Advanced Encryption Standard encryptor a while back. Ever Faithful, Don Quixote -- Don Quixote de la Mancha Dulcinea Technologies Corporation Software of Elegance and Beauty http://www.dulcineatech.com quixote at dulcineatech.com -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
I'm the code owner of LLVM codegen and targets. I'm also the one of main developers on the original ARM target. That means, I would make the decisions on major development on ARM target if there are decisions to be made. But my role is very different from what people are looking for in this thread. To properly qualify a target like ARM which are supported on many different CPUs and platforms, we need a group of volunteers. This is critical near release time for obvious reasons, but it's also welcome between releases as well. LLVM.org doesn't explicitly name these "maintainers". I personally don't see a benefit because we don't want to force people to do release qualification when they might not be available. I think what we usually do is for the release manager to gather a group of volunteered. These are the folks who are responsible for qualification the targets of their interests on their preferred platform. Evan On Oct 13, 2011, at 10:33 AM, Raja Venkateswaran wrote:> I think we need a group of maintainers rather than a single maintainer given the spectrum of ARM targets/ISAs/platforms required to support and the amount of people/system resources required. I & my team plan to actively participate in the bug-fixing process during the release cycle. If we can divide the bugs among the maintainers and establish a requirement that all open ARM bugs must be fixed/addressed (at least analyzed if cannot be fixed) by release time, it will go a long way in ensuring high quality releases for ARM > > --Raja > > From: Joe Abbey [mailto:jabbey at arxan.com] > Sent: Thursday, October 13, 2011 10:01 AM > To: Renato Golin > Cc: Anton Korobeynikov; rajav at codeaurora.org; James Molloy; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] LLC ARM Backend maintainer > > Admittedly we're very interested in becoming ARM backend maintainers as our product heavily relies on LLVM. > > However, we don't have testing resources to test both our product and LLVM on a host of target boards. We have some chumbys, beagleboards, iPhones, iPod Touches, tables, Android Phones, etc. And most of those are already booked solid with our own regression tests (most of which are based on llvm-test-suite) > > Could ARM enable us with testing hardware/resources? > > Thanks! > > Joe Abbey > Software Architect > Arxan Technologies, Inc. > 1305 Cumberland Ave, Ste 215 > West Lafayette, IN 47906 > W: 765-889-4756 x2 > C: 765-464-9893 > jabbey at arxan.com > www.arxan.com > > > > On Oct 13, 2011, at 12:48 PM, Renato Golin wrote: > > > On 11 October 2011 18:22, Anton Korobeynikov <anton at korobeynikov.info> wrote: > > 1. We should define which ARM-related features (in general, e.g. > platforms, cores, modes, etc.) we consider "release important" > 2. We should define the conditions how the features in 1. should be tested > 3. Someone should perform such testing for each release, provide help > with reproduction of the problems (consider e.g. PR11107, w/o Bill's > help it would be extremely hard to reproduce the problem, since it > manifests only on arm/darwin). > > 4. We should be able to guarantee that release-blocking bugs on ARM > targets will be fixed (if technically possible) before the actual > release. > > There is no point in define ARM as a release-blocking target if there > is no commitment in actually fixing release bugs. What keeps ARM on > the bench is just the lack of general commitment. Somebody has to own > it, for real. > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > 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/20111013/5e990c35/attachment.html>
On Oct 13, 2011, at 10:33 AM, Raja Venkateswaran wrote:> I think we need a group of maintainers rather than a single maintainer given the spectrum of ARM targets/ISAs/platforms required to support and the amount of people/system resources required. I & my team plan to actively participate in the bug-fixing process during the release cycle. If we can divide the bugs among the maintainers and establish a requirement that all open ARM bugs must be fixed/addressed (at least analyzed if cannot be fixed) by release time, it will go a long way in ensuring high quality releases for ARM >Its very unrealistic to require that all ARM bugs be fixed for a release. There is no way that this would feasible work and get the release out in a timely manner. You need to have a very concrete list of requirements to consider the release to be qualified for ARM. I suggest looking at we we currently do: http://llvm.org/docs/HowToReleaseLLVM.html#criteria Bill is going to update this to reflect us dropping llvm-gcc, but thats the general idea. When determining the release criteria, I would advise starting off small. You don't need to come up with the perfect solution up front. Pick a few tests, bootstrap, and then which processors are to be qualified. Once the criteria is established, then continuous testing needs to occur via our buildbot infrastructure. Given our short release cycle, we can't not test something for 6 months and then suddenly decide to test it during the release cycle. Too many surprise bugs will show up and may take a very long time to fix. Its much better to continuously test and have a handful of issues come release time. Volunteers are needed to be the qualifier for some arch/platform for releases. If someone is interested in filling these roles, please talk to Bill as he is the current release manager. And as always, we need volunteers to fix release blocker bugs during the release cycle. This has sometimes been big problem during a release cycle and hopefully more will start to get more volunteers. This is why we need continuous testing of release criteria because we just don't have enough volunteers to fix everything at the last minute. Lastly, anyone can contribute to the ARM backend, so I don't think there is anything really stopping people at the moment for helping "maintain" the ARM backend. Evan is the code owner who approves all changes of course. Thanks, Tanya> --Raja > > From: Joe Abbey [mailto:jabbey at arxan.com] > Sent: Thursday, October 13, 2011 10:01 AM > To: Renato Golin > Cc: Anton Korobeynikov; rajav at codeaurora.org; James Molloy; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] LLC ARM Backend maintainer > > Admittedly we're very interested in becoming ARM backend maintainers as our product heavily relies on LLVM. > > However, we don't have testing resources to test both our product and LLVM on a host of target boards. We have some chumbys, beagleboards, iPhones, iPod Touches, tables, Android Phones, etc. And most of those are already booked solid with our own regression tests (most of which are based on llvm-test-suite) > > Could ARM enable us with testing hardware/resources? > > Thanks! > > Joe Abbey > Software Architect > Arxan Technologies, Inc. > 1305 Cumberland Ave, Ste 215 > West Lafayette, IN 47906 > W: 765-889-4756 x2 > C: 765-464-9893 > jabbey at arxan.com > www.arxan.com > > > > On Oct 13, 2011, at 12:48 PM, Renato Golin wrote: > > > On 11 October 2011 18:22, Anton Korobeynikov <anton at korobeynikov.info> wrote: > > 1. We should define which ARM-related features (in general, e.g. > platforms, cores, modes, etc.) we consider "release important" > 2. We should define the conditions how the features in 1. should be tested > 3. Someone should perform such testing for each release, provide help > with reproduction of the problems (consider e.g. PR11107, w/o Bill's > help it would be extremely hard to reproduce the problem, since it > manifests only on arm/darwin). > > 4. We should be able to guarantee that release-blocking bugs on ARM > targets will be fixed (if technically possible) before the actual > release. > > There is no point in define ARM as a release-blocking target if there > is no commitment in actually fixing release bugs. What keeps ARM on > the bench is just the lack of general commitment. Somebody has to own > it, for real. > > cheers, > --renato > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > 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/20111014/1d32b672/attachment.html>