search for: kazantsev

...> > You know the codebase better than I do. > > Thanks, > Pankaj > > -----Original Message----- > From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] > Sent: Tuesday, March 13, 2018 1:34 PM > To: Chawla, Pankaj <pankaj.chawla at intel.com> > Cc: Maxim Kazantsev <max.kazantsev at azul.com>; Serguei Katkov <serguei.katkov at azul.com>; llvm-dev at lists.llvm.org > Subject: Re: [SCEV] Inconsistent SCEV formation for zext > > This sounds fine to me (and sorry for the delay!). > > -- Sanjoy > > On Mon, Mar 12, 2018 at 1:09 PM,...

...ec2k6 401.bzip2 on Cortex-A57(AArch64). https://reviews.llvm.org/D42290 “[SCEV] Clear poison flags during expansion of SCEV” * This patch tries to fix regressions due to the D41578 patch. Thanks, Evgeny Astigeevich From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Maxim Kazantsev via llvm-dev <llvm-dev at lists.llvm.org> Reply-To: Maxim Kazantsev <max.kazantsev at azul.com> Date: Thursday, 25 January 2018 at 06:03 To: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org> Subject: [llvm-dev] Late setting of SCEV NoWrap flags does bad with cach...

On Thu, Jan 25, 2018 at 9:55 PM, Maxim Kazantsev <max.kazantsev at azul.com> wrote: > I don't really believe that option 2 may work just because even if we recalculate the range for this add recurrency, there are already its derivatives with cached ranges (the most obvious example is sext and expressions where this sext is involved)....

...hem. So I would rather belive in option 1 as in the most reliable. I'll try to experiment with options 1 and 3 and see where it gets us. Best regards, Max -----Original Message----- From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] Sent: Friday, January 26, 2018 12:04 PM To: Maxim Kazantsev <max.kazantsev at azul.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Late setting of SCEV NoWrap flags does bad with cache Hi Max, On Wed, Jan 24, 2018 at 10:03 PM, Maxim Kazantsev via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I want to raise a discussion about r...

...com> wrote: > Hi Sanjoy, > > So what is the verdict on this issue? > > Thanks, > Pankaj > > > -----Original Message----- > From: Chawla, Pankaj > Sent: Monday, February 26, 2018 11:12 AM > To: Sanjoy Das <sanjoy at playingwithpointers.com> > Cc: Maxim Kazantsev <max.kazantsev at azul.com>; Serguei Katkov <serguei.katkov at azul.com>; llvm-dev at lists.llvm.org > Subject: RE: [SCEV] Inconsistent SCEV formation for zext > > Hi Sanjoy, > >>> I'm a bit apprehensive of adding more caching to solve problems created by cachin...

...y! Would it be possible for you to implement this? You know the codebase better than I do. Thanks, Pankaj -----Original Message----- From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] Sent: Tuesday, March 13, 2018 1:34 PM To: Chawla, Pankaj <pankaj.chawla at intel.com> Cc: Maxim Kazantsev <max.kazantsev at azul.com>; Serguei Katkov <serguei.katkov at azul.com>; llvm-dev at lists.llvm.org Subject: Re: [SCEV] Inconsistent SCEV formation for zext This sounds fine to me (and sorry for the delay!). -- Sanjoy On Mon, Mar 12, 2018 at 1:09 PM, Chawla, Pankaj <pankaj.chawla...

Hi Sanjoy, So what is the verdict on this issue? Thanks, Pankaj -----Original Message----- From: Chawla, Pankaj Sent: Monday, February 26, 2018 11:12 AM To: Sanjoy Das <sanjoy at playingwithpointers.com> Cc: Maxim Kazantsev <max.kazantsev at azul.com>; Serguei Katkov <serguei.katkov at azul.com>; llvm-dev at lists.llvm.org Subject: RE: [SCEV] Inconsistent SCEV formation for zext Hi Sanjoy, >> I'm a bit apprehensive of adding more caching to solve problems created by caching; but if there is no...

...at if a loop gets peeled, then a widenable condition in the loop can be optimized away basing on fact that this field was true on the 1st iteration. Thanks, Max -----Original Message----- From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] Sent: Wednesday, July 11, 2018 8:35 PM To: Maxim Kazantsev <max.kazantsev at azul.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Giving up using implicit control flow in guards Hi Max, I think this works, but I'm a bit wary around the complexity introduced by widenable_condition. For instance, we'd have to be...

Hi Sanjoy, >> I'm a bit apprehensive of adding more caching to solve problems created by caching; but if there is no way out of adding another cache, how about adding a cache that maps SCEV expressions to their simplified versions? Then we could do something like: I may be wrong but I think caching is not an issue in itself, but caching in the presence of self-recursion is. >>

Hi Max, On Wed, Jan 24, 2018 at 10:03 PM, Maxim Kazantsev via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I want to raise a discussion about reasonability of late setting of > nsw/nuw/nw flags to SCEV AddRecs through setNoWrapFlags method. A discussion > about this have already happened in August last year, there was a concern > about...

Hello Everyone, I want to raise a discussion about reasonability of late setting of nsw/nuw/nw flags to SCEV AddRecs through setNoWrapFlags method. A discussion about this have already happened in August last year, there was a concern about different no-wrap flags that come from different sequences of SCEV flags invocations. It was mentioned there that late setting of flags is actually a hack to

Adding Maxim On Apr 9, 2018, at 10:06 AM, Sam Parker via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi, extractRangeChecksFromBranch uses BranchProbabilityInfo to decide whether its worth trying the InductiveRangeCheckElimination transformation. For the following example: void split() { for (int i = 0; i < 100; ++i) { if (i < 99)

Hi, +CC Max, Serguei This looks like a textbook case of why caching is hard. We first call getZeroExtendExpr on %dec, and this call does end up returning an add rec. However, in the process of simplifying the zext, it also calls into isLoopBackedgeGuardedByCond which in turn calls getZeroExtendExpr(%dec) again. However, this second (recursive) time, we don't simplify the zext and cache a

Hi, extractRangeChecksFromBranch uses BranchProbabilityInfo to decide whether its worth trying the InductiveRangeCheckElimination transformation. For the following example: void split() { for (int i = 0; i < 100; ++i) { if (i < 99) do_something() else do_something_else() } } But the reported BPI is reported as 50/50 to whether do_something will be called, but we

...I''ll probably also be able to attach sequence of actions executed by systemd (leading to this crash) a bit later. If there''s any additional information I can provide or any test I should run on the setup, I''d be happy to do so. Thank you for your attention. -- Mike Kazantsev // fraggod.net

Hi Sanjoy, SCEV is behaving inconsistently when forming SCEV for this zext instruction in the attached test case- %conv5 = zext i32 %dec to i64 If we request a SCEV for the instruction, it returns- (zext i32 {{-1,+,1}<nw><%for.body>,+,-1}<nw><%for.body7> to i64) This can be seen by invoking- $ opt -analyze -scalar-evolution inconsistent-scev-zext.ll But when computing

...time implications. A better solution is more that welcome. Please let me know your thoughts. Thanks, Pankaj -----Original Message----- From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] Sent: Friday, February 09, 2018 4:46 PM To: Chawla, Pankaj <pankaj.chawla at intel.com>; Maxim Kazantsev <max.kazantsev at azul.com>; Serguei Katkov <serguei.katkov at azul.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [SCEV] Inconsistent SCEV formation for zext Hi, +CC Max, Serguei This looks like a textbook case of why caching is hard. We first call getZeroExtendExpr on %dec, and...

Good day, Dovecot includes nice unit files for systemd, but I've noticed that "systemctl enable dovecot.service" fails because service file does not include Install section. I assume that is because there's a .socket file, but there might be reasons when you want to enable it as a service. In my case it's one of the main services on the machine, so I'd like to see

Hello Everyone, I want to raise a discussion about @llvm.experimental.guard intrinsic and reasons why we should give up using it. Here is an alternative approach to representation of guards that resolves some of fundamental flaws that the current guards have. Basically, this intrinsic was introduced to model the following situation: we want to check that some condition is true, and if it's

Hi, I found issues with INDVARS <-> LSR passes interactions after https://reviews.llvm.org/rL346397. There were two main changes in this commit: 1. Previously we were propagating SCEV add expressions even if DefInst of exit value has hard uses inside the loop. After rL346397 we forbid propagation of SCEV add expressions if DefInst of exit value has hard use inside the loop. 2. Previously