search for: nts

...ething change with exception handling recently? A bunch of lit bots are showing slower compile times for many tests. Ciao, Duncan. On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu wrote: > > lab-mini-03__O0-g__clang_DEV__x86_64 test results > <http://llvm.org/perf/db_default/v4/nts/1283?compare_to=1278&baseline=999> > > Run Order Start Time Duration > Current <http://llvm.org/perf/db_default/v4/nts/1283> 158786 > <http://llvm.org/perf/db_default/v4/nts/order/1314> 2012-06-20 03:39:48 2:15:27 > Previous <http://llvm.org/perf/db_default/v...

...g recently? A bunch of lit bots are > showing slower compile times for many tests. > > Ciao, Duncan. > > On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu wrote: >> >> lab-mini-03__O0-g__clang_DEV__x86_64 test results >> <http://llvm.org/perf/db_default/v4/nts/1283?compare_to=1278&baseline=999> >> >> Run Order Start Time Duration >> Current <http://llvm.org/perf/db_default/v4/nts/1283> 158786 >> <http://llvm.org/perf/db_default/v4/nts/order/1314> 2012-06-20 03:39:48 2:15:27 >> Previous <http://llvm....

...s are >> showing slower compile times for many tests. >> >> Ciao, Duncan. >> >> On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu wrote: >>> >>> lab-mini-03__O0-g__clang_DEV__x86_64 test results >>> <http://llvm.org/perf/db_default/v4/nts/1283?compare_to=1278&baseline=999> >>> >>> Run Order Start Time Duration >>> Current <http://llvm.org/perf/db_default/v4/nts/1283> 158786 >>> <http://llvm.org/perf/db_default/v4/nts/order/1314> 2012-06-20 03:39:48 2:15:27 >>> Previo...

Are these 225 compile time regressions real? It sure looks bad! Ciao, Duncan. On 01/12/11 09:39, llvm-testresults at cs.uiuc.edu wrote: > > bwilson__llvm-gcc_PROD__i386 nightly tester results > > URL http://llvm.org/perf/db_default/simple/nts/380/ > Nickname bwilson__llvm-gcc_PROD__i386:4 > Name curlew.apple.com > > Run ID Order Start Time End Time > Current 380 0 2011-12-01 07:59:12 2011-12-01 08:42:06 > Previous 379 0 2011-11-30 08:13:45 2011-11-30 08:56:22 > > > Tests Summary > > Status Grou...

...compile times for many tests. >>> >>> Ciao, Duncan. >>> >>> On 20/06/12 07:53, llvm-testresults at cs.uiuc.edu wrote: >>>> >>>> lab-mini-03__O0-g__clang_DEV__x86_64 test results >>>> <http://llvm.org/perf/db_default/v4/nts/1283?compare_to=1278&baseline=999> >>>> >>>> Run Order Start Time Duration >>>> Current <http://llvm.org/perf/db_default/v4/nts/1283> 158786 >>>> <http://llvm.org/perf/db_default/v4/nts/order/1314> 2012-06-20 03:39:48 2:15:27 &g...

On 07/30/2013 10:03 AM, Star Tan wrote: > Hi Tobias and all Polly developers, > > I have re-evaluated the Polly compile-time performance using newest > LLVM/Polly source code. You can view the results on > http://188.40.87.11:8000 > <http://188.40.87.11:8000/db_default/v4/nts/16?compare_to=9&baseline=9&aggregation_fn=median>. > > Especially, I also evaluated ourr187102 patch file that avoids expensive > failure string operations in normal execution. Specifically, I evaluated > two cases for it: > > Polly-NoCodeGen: clang -O3 -load LLVMPolly....

...so evaluated our r187102 patch file that avoids expensive failure string operations in normal execution. Specifically, I evaluated two cases for it: Polly-NoCodeGen: clang -O3 -load LLVMPolly.so -mllvm -polly-optimizer=none -mllvm -polly-code-generator=none http://188.40.87.11:8000/db_default/v4/nts/16?compare_to=9&baseline=9&aggregation_fn=median Polly-Opt: clang -O3 -load LLVMPolly.so -mllvm -polly http://188.40.87.11:8000/db_default/v4/nts/18?compare_to=11&baseline=11&aggregation_fn=median The "Polly-NoCodeGen" case is mainly used to compare the compile-time perf...

I am trying to call a funtion within another function and I clearly am misunderstanding what I should do. Below is a simple example. I know lstfun works on its own but I cannot seem to figure out how to get it to work within ukn. Basically I need to create the variable "nts". I have probably missed something simple in the Intro or FAQ. Any help would be much appreciated. EXAMPLE ------------------------------------------------------------------------------- # create data.frame cata <- c( 1,1,6,1,1,4) catb <- c( 1,2,3,4,5,6) id <- c('a', 'b&...

...AM, Star Tan wrote: >> Hi Tobias and all Polly developers, >> >> I have re-evaluated the Polly compile-time performance using newest >> LLVM/Polly source code. You can view the results on >> http://188.40.87.11:8000 >> <http://188.40.87.11:8000/db_default/v4/nts/16?compare_to=9&baseline=9&aggregation_fn=median>. >> >> Especially, I also evaluated ourr187102 patch file that avoids expensive >> failure string operations in normal execution. Specifically, I evaluated >> two cases for it: >> >> Polly-NoCodeGen: cl...

...;>> Hi Tobias and all Polly developers, >>> >>> I have re-evaluated the Polly compile-time performance using newest >>> LLVM/Polly source code. You can view the results on >>> http://188.40.87.11:8000 >>> <http://188.40.87.11:8000/db_default/v4/nts/16?compare_to=9&baseline=9&aggregation_fn=median>. >>> >>> Especially, I also evaluated ourr187102 patch file that avoids expensive >>> failure string operations in normal execution. Specifically, I evaluated >>> two cases for it: >>> >>...

...h as flat but noisy line, 5% regression in 5% noise, bimodal, and a slow increase, we fail to classify most of these correctly right now. They are not trick questions, all are obvious regressions or non-regressions, that are plainly visible. I want us to correctly classify them all! Some context: LNTs regression detection algorithm as I understand it: detect(current run’s samples, last runs samples) —> improve, regress or unchanged. # when recovering from errors performance should not be counted Current or last run failed -> unchanged delta = min(current samples) - min(prev...

...all are obvious regressions or non-regressions, that are >> plainly visible. I want us to correctly classify them all! > > That's a great idea! > Out of all of the ideas in this email, I think this is the most important > one to implement first. > >> Some context: LNTs regression detection algorithm as I understand it: >> >> detect(current run’s samples, last runs samples) —> improve, regress or >> unchanged. >> >> # when recovering from errors performance should not be counted >> Current or last run failed -> unc...

...and all Polly developers, >>>> >>>> I have re-evaluated the Polly compile-time performance using newest >>>> LLVM/Polly source code. You can view the results on >>>> http://188.40.87.11:8000 >>>> <http://188.40.87.11:8000/db_default/v4/nts/16?compare_to=9&baseline=9&aggregation_fn=median>. >>>> >>>> Especially, I also evaluated ourr187102 patch file that avoids expensive >>>> failure string operations in normal execution. Specifically, I evaluated >>>> two cases for it: >&...

...by this profile I moved some patterns under the "if >> (ExpensiveCombines)" check, which expectedly happened to be neutral >> for runtime performance, but improved compile-time. The testing >> results are below (measured for Os). >> >> Performance Improvements - Compile Time Δ Previous Current σ >> CTMark/sqlite3/sqlite3 >> <http://michaelsmacmini.local/perf/v4/nts/2/graph?test.15=2> -1.55% >> 6.8155 6.7102 0.0081 >> CTMark/mafft/pairlocalalign >> <http://michaelsmacmini.local/perf/v4/nts/2/graph?test.1=2&...

...e report: (beware, the file is ~6MB). Guided by this profile I moved some patterns under the "if (ExpensiveCombines)" check, which expectedly happened to be neutral for runtime performance, but improved compile-time. The testing results are below (measured for Os). Performance Improvements - Compile Time Δ Previous Current σ CTMark/sqlite3/sqlite3 <http://michaelsmacmini.local/perf/v4/nts/2/graph?test.15=2> -1.55% 6.8155 6.7102 0.0081 CTMark/mafft/pairlocalalign <http://michaelsmacmini.local/perf/v4/nts/2/graph?test.1=2> -1.05% 8.0407 7.9559 0.0193 CTMark/ClamAV/clamsca...

Hi, I have just tagged 3.7.1-rc1, so it is ready for testing. As a reminder, when doing regression testing, use the 3.7.0 release as your baseline. Thanks, Tom

...ooks like these > haven't run [1] since the move from svn to git -- are there any plans > to get these running again? I find it highly useful to identify what > commits have affected variable locations and how significant an > affect. > > [0] http://lnt.llvm.org/db_default/v4/nts/graph?plot.0=1357.1607042.4 > [1] http://lnt.llvm.org/db_default/v4/nts/machine/1357 > > -- > Thanks, > Jeremy > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/...

...variables with locations. It looks like these haven't run [1] since the move from svn to git -- are there any plans to get these running again? I find it highly useful to identify what commits have affected variable locations and how significant an affect. [0] http://lnt.llvm.org/db_default/v4/nts/graph?plot.0=1357.1607042.4 [1] http://lnt.llvm.org/db_default/v4/nts/machine/1357 -- Thanks, Jeremy

Hello all, I have done some basic experiments about Polly canonicalization passes and I found the SCEV canonicalization has significant impact on both compile-time and execution-time performance. Detailed results for SCEV and default canonicalization can be viewed on: http://188.40.87.11:8000/db_default/v4/nts/32 (or 33, 34) *pNoGen with...

...he SimplifyDemandedInstructionBits and foldICmpUsingKnownBits calls being the obvious expensive routines). > > The purpose of many of InstCombine's xforms is to canonicalize the IR to make life easier for downstream passes and analyses. As we get further along with compile-time improvements one question we need to ask ourselves more frequently is about the effectiveness of optimizations/passes. For example - in this case - how can we make an educated assessment that running the combiner N times is a good cost/benefit investment of compute resources? The questions below are meant to f...