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 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. -Dave
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
Hal Finkel <hfinkel at anl.gov> writes:>> 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?I can't make that decision and I very much doubt we could even do it. It's quite tied in to our entire release mechanism. Remember, this is a process that has been going for 30 years or more.> 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.Actually, we don't have any problem releasing tests. We have done so before when sending patches. The problem is the people we got the tests from. Some are from proprietary test suites, others are from sensitive codes, etc. It's often not up to us at all. A larger problem, I think, is that patches often get dropped and/or they take forever to get approved. The red tape is astounding. You ran into that with your scheduler change, which is obviously a Good Thing to us and would support users of 3.0 and 3.1 very well even if it were to be deprecated in 3.2. But yet it hasn't made it in and it looks like it would not be accepted no matter what. That is a symptom of the problem.>> 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.Yes, I completely understand the reasoning and in an ideal world I would like to live off trunk. But if trunk is meant to be stable, why have releases at all? There must be value added to releases or we just shouldn't do them. It's that added value that we're counting on.> 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.As I said, we release monthy updates. Major releases are generally once a year but sometimes more frequently. LLVM doesn't do point releases and that's another issue we have to deal with. As I said, I am working on integrating trunk into our development tree via git as an experiment. Maybe it will work out really well and we'll be able to switch but I'm not counting on that. I think the LLVM project is mature enough that we really should be considering supporting release users much better. But of course that's coming from a selfish position. :) Still, I think it is a valid discussion to have. -Dave
On May 10, 2012, at 12:01 PM, Hal Finkel wrote:> 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.Just to clarify here, "Apple" release have nothing to do with llvm.org releases. The LLVM.org schedule is purely time-driven (a ~6 month cycle), and done by volunteers - including the @apple.com people who contribute to the releases. The Apple schedule is quite variable, and often a lot more frequent than every 6 months. This is why Apple release have always been based off a random revision number, usually irritatingly right in the middle of an llvm.org release.> 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 thereThis is just one more reason that it is important to me for the trunk to remain stable. -Chris