similar to: [LLVMdev] LLVMdev Digest, Vol 88, Issue 29

I am very interested in seeing a qualification plan for ARM given that it is a widely used target with several combinations of options/modes to be tested. I & my team use ARM hardware for running tests and we run all LLVM test suite tests as part of qualification process. I had started a similar conversation in llvm-commits, but this is probably the right forum. It will save everyone a lot of

Hi, It goes without saying that I +1 this. Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Raja Venkateswaran Sent: 11 October 2011 17:46 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LLC ARM Backend maintainer I am very interested in seeing a qualification plan for ARM given that it is a widely used

Hi Raja, I'm open to suggestions. Our current release qualification is to bootstrap the compiler (similar to how GCC does their bootstrapping), run the test suites, and verify that there are no regressions. Improving the test suite is always welcome. In addition, we send out pre-release tarballs and have people in the community build and test their programs with it. This is not a perfect

No. Note the qualifying phrase "for releases" on Tanya's statement. If, during release testing, a regression is found on ARM compared to 2.9 results, it is not required by process to be considered a release blocker. That does not mean features can or should be enabled which knowingly break ARM. That's an entirely different situation. -Jim On Oct 8, 2011, at 9:59 AM, Rotem,

Hi Tanya, The new type-legalization mode (-promote-elements) which enables vector-select in LLVM (and a nice perf boost for several workloads), is currently disabled because of a _single_ bug in the ARM codegen which makes a few tests fail. If ARM is not a supported target, can I mark these tests as 'XFAIL' and enable vector-select support in LLVM ? Thanks, Nadav -----Original

On Oct 7, 2011, at 1:07 AM, Seb wrote: > Hi all, > > To answer Eli question, I wanted to know who is actively working on ARM because I submitted some bug report (#11029, #9905) and don't know if someone is working on them, if/when the will be fixed. Maybe I just need to better understand LLVM release process, I've seen a mail in this list about it. Bugs get fixed if there are

Hi all, To answer Eli question, I wanted to know who is actively working on ARM because I submitted some bug report (#11029, #9905) and don't know if someone is working on them, if/when the will be fixed. Maybe I just need to better understand LLVM release process, I've seen a mail in this list about it. -- Seb -------------- next part -------------- An HTML attachment was scrubbed...

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

Bill Wendling <wendling at apple.com> writes: > Improving the test suite is always welcome. Do we have an idea of what sorts of improvements we'd like? Any codes that we want to add, for example? What would be useful for ARM? > In addition, we send out pre-release tarballs and have people in the > community build and test their programs with it. This is not a perfect >

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

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>

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

On Oct 11, 2011, at 2:43 PM, David A. Greene wrote: > Bill Wendling <wendling at apple.com> writes: > >> Improving the test suite is always welcome. > > Do we have an idea of what sorts of improvements we'd like? Any codes > that we want to add, for example? What would be useful for ARM? > >> In addition, we send out pre-release tarballs and have

I think we need to think along two dimensions - Breadth of testing and depth of testing 1. Breadth: What the best supported ARM ISA versions in LLVM ARM? Say its armv6 and armv7; We need to - regression test ARM mode, Thumb-2 and Thumb-1 mode (armv6) - Performance/code-size test ARM mode, Thumb-2 and Thumb-1 modes We need to agree on an optimization level for regression as well as

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

On Apr 7, 2009, at 6:02 PM, Tanya M. Lattner wrote: > Can you please just respond to the specific patch on llvm-commits > instead > of emailing llvm-dev? Don't happen to know which checkin caused it...

LLVMers, As LLVM grows and begins to support more targets and more frontends, its becoming a very large task to qualify a release. Therefore, I'm seeking a couple of active members of the community to volunteer to be a part of the LLVM release team (for 2.6+). This does not replace general user testing during the release process. Members of this LLVM Release Team will need to be very

All, There has been a huge lack of response to the release. We need people to help fix regressions and to participate in testing the release. Without this support, I see no reason that the release team should spend their time qualifying a release. We need to get all regressions fixed before 2.7 can continue onto pre-release2. Please take a look at all release blockers:

The 2.7 pre-release2 is available for testing: http://llvm.org/pre-releases/2.7/pre-release2/ Please complete all testing by April 23rd EOD. We are shortening this testing period a bit to get the release out soon since its been delayed so far. The release team has done our qualifications and we think its of high quality and ready to go. As this is the last pre-release, we only accept fixes for

On Tuesday 30 March 2010 16:09:03 Tanya Lattner wrote: > Please take a look at all release blockers: > http://llvm.org/bugs/show_bug.cgi?id=6586 5893 is not release-critical according to Doug. 6640 appears to be a test system problem with a patch available (one of the ones you're working on?) Which bugs do you have patches for? I don't want to start looking at something if