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>
I see, so perhaps the LLVM ARM Backend is in need of a method of organizing volunteer qualifiers, as releases near? Has this generally been organized via this mailing list? Joe 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<http://www.arxan.com/> On Oct 13, 2011, at 2:44 PM, Evan Cheng wrote: 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<http://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<mailto:rajav at codeaurora.org>; James Molloy; llvmdev at cs.uiuc.edu<mailto: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<mailto:jabbey at arxan.com> www.arxan.com<http://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://llvm.cs.uiuc.edu/> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.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/bd0ea157/attachment.html>
On Oct 13, 2011, at 12:33 PM, Joe Abbey wrote:> I see, so perhaps the LLVM ARM Backend is in need of a method of organizing volunteer qualifiers, as releases near? > > Has this generally been organized via this mailing list? >Yes. Bill Wendling manages the releases, so you'll want to coordinate with him. -Jim> Joe > > 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 2:44 PM, Evan Cheng wrote: > >> 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 >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
The benefit of having people run tests on ARM during the release process is to ferret out bugs that could potentially affect our release platforms. I don't want or expect people to spend all of their time doing full release testing on a platform we aren't going to officially support in 3.0. But during the release, we do generate source tarballs and ask people to download them and test them. I would encourage ARM developers to test them. That said, we are not looking to officially support ARM for the 3.0 release. It's too late in the process to change the officially supported platforms list. -bw On Oct 13, 2011, at 11:44 AM, Evan Cheng wrote:> 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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev