[LLVMdev] LLC ARM Backend maintainer

Kristof Beyls kristof.beyls at arm.com
Mon Oct 17 04:30:54 PDT 2011


I agree with the remarks made by Tanya.

 

Our team plans to actively help fix release blocker bugs for ARM targets.

However, clear release criteria need to be defined for that, so that it's
clear which bugs are release blockers. Additionally, continuous testing
needs to be set up to automatically determine whether there are any release
blocker bugs or not.

 

Maybe we could have a BoF session during the conference on the 18th of
November to come up with a basic set of release criteria for ARM targets?

 

Thanks,

 

Kristof

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Tanya Lattner
Sent: 14 October 2011 22:32
To: rajav at codeaurora.org
Cc: James Molloy; 'Joe Abbey'; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] LLC ARM Backend maintainer

 

 

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/20111017/6017656e/attachment.html>


More information about the llvm-dev mailing list