llvm dev - Oct 2011 - [LLVMdev] LLC ARM Backend maintainer

Hi James,
> It goes without saying that I +1 this.
Well, the answer should be pretty easy, I think:

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).

Any volunteers? :)

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

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

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>