[LLVMdev] Scheduler Roadmap

[Hal Finkel]

On Thu, 10 May 2012 11:24:12 -0500
<dag at cray.com> wrote:

> Hal Finkel <hfinkel at anl.gov> writes:
> 
> > Out of curiosity, can your frontend be configured to produce LLVM IR
> > that could be fed though the trunk backend passes, or is a tighter
> > integration required? 
> 
> Yes, we have this capability.
> 
> > If it is possible to produce LLVM IR, then it might be possible to
> > test a lot, although not all, of the upstream changes using your
> > internal test suite in combination with the generic trunk backend
> > in a fairly straightforward manner. 
> 
> Unfortuantely out test system isn't set up to accept LLVM IR files.
> This is something I've wanted to have implemented for a long time but
> we're all stretched pretty thin here.
> 
> > It might even be possible to setup a system to warn the upstream
> > developers when we've broken something.
> 
> I would like that very much.  It's a resource issue, not a technical
> one.

I think that it might be useful to think about changing the parameters
of this optimization problem. Could you release enough of the testing
system so that others could help? Could you release (some subset of) the
tests as LLVM IR so that they could be integrated with the existing
buildbots? I understand that you may view these things as valuable IP,
but in reality, the opportunity cost of not sharing may far outweigh
any competitive advantage you get by not sharing.

> 
> I think it's pretty common for teams producing production-quality code
> to want to base pieces off of tested and released software.  I had
> never head of any company doing otherwise until Apple with LLVM.
> It's not the normal way to produce releases off an unstable trunk.

As far as I can tell, Apple tries very hard to keep trunk stable; it is
one of the most stable trunks with which I've worked. Obviously there
are regressions, but these tend to have a short lifespan. One of the
advantages of keeping a relatively stable trunk is that they get more
trunk testers, and that, in turn, help keeps trunk stable. As a result,
they can take releases from trunk, and this gives them a short
turn-around time on new features with low backporting overhead.

The disadvantage for outsiders is, however, that it forces your
releases to follow their releases (because of additional stabilization
activity prior to releases), and that may not be practical if your
release cycle is shorter than theirs. However, if the release cycle is
too short for the project's users, then we should think about
shortening it.

Thanks again,
Hal

> 
>                                -Dave



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory