similar to: llvm (the middle-end) is getting slower, December edition

> On Dec 17, 2016, at 1:35 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > First of all, sorry for the long mail. > Inspired by the excellent analysis Rui did for lld, I decided to do > the same for llvm. > I'm personally very interested in build-time for LTO configuration, > with particular attention to the time spent in the optimizer. >

> On Dec 17, 2016, at 1:35 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > First of all, sorry for the long mail. > Inspired by the excellent analysis Rui did for lld, I decided to do > the same for llvm. > I'm personally very interested in build-time for LTO configuration, > with particular attention to the time spent in the optimizer. >

On Sat, Dec 17, 2016 at 6:39 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Dec 17, 2016, at 1:35 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> First of all, sorry for the long mail. >> Inspired by the excellent analysis Rui did for lld, I decided to do >> the same for llvm. >> I'm personally very

On Sat, Dec 17, 2016 at 1:35 PM, Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > First of all, sorry for the long mail. > Inspired by the excellent analysis Rui did for lld, I decided to do > the same for llvm. > I'm personally very interested in build-time for LTO configuration, > with particular attention to the time spent in the optimizer. >

On 12/17/2016 01:35 PM, Davide Italiano via llvm-dev wrote: > First of all, sorry for the long mail. > Inspired by the excellent analysis Rui did for lld, I decided to do > the same for llvm. > I'm personally very interested in build-time for LTO configuration, > with particular attention to the time spent in the optimizer. > Rafael did something similar back in March, so

Hi Davide, Thanks for the analysis, it's really interesting! And I'm really glad that we now put more and more attention at the compile time! Just recently I've been looking into historical compile time data as well, and have had similar conclusions. The regressions you've found are probably caused by: 1) r289813 and r289855 - new matchers in InstCombine 2) r286814 and r288024 -

On 2016-09-27 02:28, Philip Reames wrote: > On 09/20/2016 12:05 PM, Matti Niemenmaa via llvm-dev wrote: >> I posted some questions related to implementing inference of nsw/nuw >> flags based on known icmp results to Bug 30428 ( >> https://llvm.org/bugs/show_bug.cgi?id=30428 ) and it was recommended >> that I engage a wider audience by coming here. The minimal context is

On Sun, Feb 5, 2017 at 3:41 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Thanks for the answers! The plan makes sense to me. > > Regarding phis, what about diamonds, e.g.: > > > define i32 @f(i32 %x) { > br .., label %bb0, label %bb1 > bb0: > %cmp = icmp sge i32 %x, 0 ; x > 0 > br i1 %cmp, label %bb2, label %bb3 > bb1: > %x2 = add nsw

----- Original Message ----- > From: "Daniel Berlin via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Joerg Sonnenberger" <joerg at britannica.bec.de>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Thursday, January 14, 2016 10:38:10 AM > Subject: Re: [llvm-dev] High memory use and LVI/Correlated Value > Propagation > On

On Wed, Jan 13, 2016 at 04:28:03PM -0800, Daniel Berlin wrote: > On Wed, Jan 13, 2016 at 4:23 PM, Joerg Sonnenberger via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > On Wed, Jan 13, 2016 at 03:38:24PM -0800, Philip Reames wrote: > > > I don't think that arbitrary limiting the complexity of the search is the > > > right approach. There are

Hello. This question has come up in https://reviews.llvm.org/D70043 There, i'm teaching ConstantRange how no-wrap flags affect the range of `mul` instruction, with end goal of exploiting this in LVI/CVP. There are certain combinations of ranges and no-wrap flags that result in always-overflowing `mul`. For example, `mul nuw nsw i4 [2,0), [4,0)` always overflows:

On 09/09/2013 05:18 AM, Star Tan wrote: > > At 2013-09-09 05:52:35,"Tobias Grosser" <tobias at grosser.es> wrote: > >> On 09/08/2013 08:03 PM, Star Tan wrote: >> Also, I wonder if your runs include the dependence analysis. If this is >> the case, the numbers are very good. Otherwise, 30% overhead seems still >> to be a little bit much. > I think

Hi all, with the current trunk I have two major cases where clang needs more than 2GB memory for compiling programs with -O2. One is related to GVN and MemoryDependenceAnalysis and has a pending patch. The other is related to the Correlated Value Propagation and Lazy Value Information cache. Attached is a heap profile for one of the relevant test cases. Looking at the sources, I don't see any

On Wed, Jan 13, 2016 at 03:38:24PM -0800, Philip Reames wrote: > I don't think that arbitrary limiting the complexity of the search is the > right approach. There are numerous ways the LVI infrastructure could be > made more memory efficient. Fixing the existing code to be memory efficient > is the right approach. Only once there's no more low hanging fruit should > we

At 2013-09-09 05:52:35,"Tobias Grosser" <tobias at grosser.es> wrote: >On 09/08/2013 08:03 PM, Star Tan wrote: >> 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. > >Interesting. > >>

At 2013-09-09 13:07:07,"Tobias Grosser" <tobias at grosser.es> wrote: >On 09/09/2013 05:18 AM, Star Tan wrote: >> >> At 2013-09-09 05:52:35,"Tobias Grosser" <tobias at grosser.es> wrote: >> >>> On 09/08/2013 08:03 PM, Star Tan wrote: >>> Also, I wonder if your runs include the dependence analysis. If this is >>> the

Looks like LVI actually does have cases for max and min; would it be better to allow ValueTracking to use range analysis instead? - CL > On Aug 1, 2016, at 8:44 PM, Philip Reames <listmail at philipreames.com> wrote: > >> On 07/29/2016 07:08 PM, Carlos Liam via llvm-dev wrote: >> Hi all, >> >> Say we have this IR: >> >> %1 = icmp slt i16 %x, 0

On 01/13/2016 04:28 PM, Daniel Berlin via llvm-dev wrote: > > > On Wed, Jan 13, 2016 at 4:23 PM, Joerg Sonnenberger via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > On Wed, Jan 13, 2016 at 03:38:24PM -0800, Philip Reames wrote: > > I don't think that arbitrary limiting the complexity of the > search

Is the following developed in my console output a recognized bug or am I using the cat function incorrectly? Thanks, Stan > ifelse(class(data[[n]])!="factor",{print("yes")},{print("no")}) [1] "yes" [1] "yes" > ifelse(class(data[[n]])!="factor",{cat("yes")},{cat("no")}) yesError in ans[test & !nas] <-

Hi all! I tried to perform Shapiro-Wilk test for my sample of 243 values. > Us [1] -10.4 -13.1 -12.2 38.1 -18.8 -13.3 -11.7 29.3 49.7 6.8 12.7 16.3 [13] 5.8 -0.7 -29.4 4.1 38.8 -1.4 8.8 15.6 32.9 -5.3 19.1 35.8 [25] 4.0 -1.5 0.6 -4.2 -10.0 -4.0 1.1 48.9 -21.0 -5.3 5.8 -10.8 [37] 21.9 8.2 -3.2 -3.9 -2.3 12.6 -4.7 -8.0 11.8 27.4 -9.5 -20.8 [49]