On Wed, Feb 18, 2015 at 3:01 PM, Renato Golin <renato.golin at linaro.org> wrote:> On 18 February 2015 at 19:52, Jack Howarth > <howarth.mailing.lists at gmail.com> wrote: >> Assuming that the clang-omp >> developers can find time to rebase their upstream tree on the new 3.6 >> release, I intend to do the same for the fink llvm36 packaging. So >> yes, a stable compiler does matter to some folks. > > So it seems that you're one of the very few people that doesn't use > ToT. Almost everyone else uses it and the progress of LLVM kind of > assume you do. >I believe MacPorts uses the major llvm releases for their toolchain these days as the older supported systems don't have access to the latest Xcode (due to SDK deprecation).> The past releases didn't mean much until we started doing the > dot-releases, and even those didn't mean much in the first iterations. > You can't blame people for not caring that much for something that so > few people actually use it.Well, I assumed that llvm releases were supposed to be more than just glorified semi-annual snapshots.> > I think that buildbots make us rely a lot more on inter-release master > branches than we should. Maybe once more OS distributions start > relying on LLVM we'll have to match a more professional release cycle, > but for now, we have very little reason to. > > I'm perfectly happy to open a bug for each one of that Phoronix run's > regressions and fix throughout the next six months... > > cheers, > --renato
On Wed, Feb 18, 2015 at 3:10 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote:> On Wed, Feb 18, 2015 at 3:01 PM, Renato Golin <renato.golin at linaro.org> wrote: >> On 18 February 2015 at 19:52, Jack Howarth >> <howarth.mailing.lists at gmail.com> wrote: >>> Assuming that the clang-omp >>> developers can find time to rebase their upstream tree on the new 3.6 >>> release, I intend to do the same for the fink llvm36 packaging. So >>> yes, a stable compiler does matter to some folks. >> >> So it seems that you're one of the very few people that doesn't use >> ToT. Almost everyone else uses it and the progress of LLVM kind of >> assume you do. >> > > I believe MacPorts uses the major llvm releases for their toolchain > these days as the older supported systems don't have access to the > latest Xcode (due to SDK deprecation). > >> The past releases didn't mean much until we started doing the >> dot-releases, and even those didn't mean much in the first iterations. >> You can't blame people for not caring that much for something that so >> few people actually use it. > > Well, I assumed that llvm releases were supposed to be more than just > glorified semi-annual snapshots. >Also doesn't FreeBSD use the standard major llvm releases for their system compilers? Somehow, I doubt that they would be thrilled to have to resort to svn trunk.>> >> I think that buildbots make us rely a lot more on inter-release master >> branches than we should. Maybe once more OS distributions start >> relying on LLVM we'll have to match a more professional release cycle, >> but for now, we have very little reason to. >> >> I'm perfectly happy to open a bug for each one of that Phoronix run's >> regressions and fix throughout the next six months... >> >> cheers, >> --renato
On 18 February 2015 at 20:10, Jack Howarth <howarth.mailing.lists at gmail.com> wrote:> Well, I assumed that llvm releases were supposed to be more than just > glorified semi-annual snapshots.It's that time of the year that we get all together and run some tests and benchmarks we normally don't run the rest of the year, but we stop the analogy short of giving each other presents. :) So far we've being pretty good at spotting regressions like that and fixing them later, and people like Michael will keep us on our toes if we deliver it again with the regression, or if we deviate too much from GCC. cheers, --renato
On 18 February 2015 at 20:18, Jack Howarth <howarth.mailing.lists at gmail.com> wrote:> Also doesn't FreeBSD use the standard major llvm releases for their > system compilers? Somehow, I doubt that they would be thrilled to have > to resort to svn trunk.AFAIK, they use some commit between releases that they know it's stable for them, like everyone else. It's not because people call it "3.6" that it was actually extracted from "release_36" branch at the "final" tag. cheers, --renato
David Chisnall
2015-Feb-18 20:41 UTC
[LLVMdev] [cfe-dev] [3.6 Release] RC3 has been tagged
On 18 Feb 2015, at 20:18, Jack Howarth <howarth.mailing.lists at gmail.com> wrote:> > Also doesn't FreeBSD use the standard major llvm releases for their > system compilers?We do pull in releases, but Dimitry also cherry-picks bug fixes throughout the life of each release. David
Mehmet Erol Sanliturk
2015-Feb-18 21:16 UTC
[LLVMdev] [cfe-dev] [3.6 Release] RC3 has been tagged
On Wed, Feb 18, 2015 at 12:19 PM, Renato Golin <renato.golin at linaro.org> wrote:> On 18 February 2015 at 20:10, Jack Howarth > <howarth.mailing.lists at gmail.com> wrote: > > Well, I assumed that llvm releases were supposed to be more than just > > glorified semi-annual snapshots. > > It's that time of the year that we get all together and run some tests > and benchmarks we normally don't run the rest of the year, but we stop > the analogy short of giving each other presents. :) > > So far we've being pretty good at spotting regressions like that and > fixing them later, and people like Michael will keep us on our toes if > we deliver it again with the regression, or if we deviate too much > from GCC. > > cheers, > --renato > _______________________________________________ >By looking at some numbers only and say that "Performance increased" or "Performance decreased" is not a correct way of decision making . It is necessary to specify a set of programs which will be a representative sample of real life usage population ( it is necessary to exceed at least 60 programs to be able to assume "Central Limit Theorem" is valid , i.e. , sample is from a "Normal Distribution" ) . Then by using the SAME execution environment ( means the SAME programs running in the computers , best is not to run any programs other than compilation and running the program , the computers may be in any model , from 500 MHz to 5 GHz , with different operating systems ) . After obtaining compilation times , they should be analysed by using a convenient statistical package to test equality of variances and equality of means by using "Pair-wise correlated values" . Assume tests revealed that "Differences are not significant" , then to say that "There is a performance loss" is not correct . If variances are different ( populations are not from the SAME distribution ) , either variability of computations are increased or decreased : Decrease is good , increase requires inspection . If means are different ( populations are not from the SAME distribution ) , either average time of computations are increased or decreased : Decrease is good , increase requires inspection . Repeat the above computations for - - No optimization - Optimizations applied Then reasons should be checked one by one , for example : (1) Assume a bug is corrected by introducing a check : Is it possible to remove the corrections and keep the bug to increase the speed ? Obviously NO . (2) In one point , optimization is ignoring a feature , but it is not a bug ( assume optimization is not applied ) . (3) During code generation , there are redundant parts which may be eliminated . This is not a bug , but slowing down computation , because the computed values will not be affected . (4) Instead letting the programs crash blindly some new checks are introduced to prevent blind crashing : Is it necessary to eliminate such checks . Then , it will be decided which points need improvement , and which points will be kept as it is . Without doing such analyses , and pursuing a discussion on some pure different numbers and making decisions will not contribute anything to development of Clang/LLVM . Thank you very much . Mehmet Erol Sanliturk -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150218/79805e12/attachment.html>