search for: setnowrapflag

Hi, On Tue, Aug 8, 2017 at 12:58 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > Oh, I see... yes, we do stupid things involving mutating NoWrap flags after > a SCEV is created. (grep for setNoWrapFlags in ScalarEvolution.cpp.) That's really a compile time hack -- we defer some expensive tricks to prove nsw/nuw on an add recurrences to when we've been asked to sign/zero extend said add recurrence. I would be okay if you wanted to expose those tricks via a helper in SCEV that could be ca...

...te: >> >> Hi, >> >> On Tue, Aug 8, 2017 at 12:58 PM, Friedman, Eli <efriedma at codeaurora.org> >> wrote: >>> >>> Oh, I see... yes, we do stupid things involving mutating NoWrap flags >>> after >>> a SCEV is created. (grep for setNoWrapFlags in ScalarEvolution.cpp.) >> >> >> That's really a compile time hack -- we defer some expensive tricks to >> prove nsw/nuw on an add recurrences to when we've been asked to >> sign/zero extend said add recurrence. > > > If that is the case, preserving...

...on' is done by this piece of code inside getZeroExtendExpr()- // Cache knowledge of AR NW, which is propagated to this // AddRec. Negative step causes unsigned wrap, but it // still can't self-wrap. const_cast<SCEVAddRecExpr *>(AR)->setNoWrapFlags(SCEV::FlagNW); // Return the expression with the addrec on the outside. return getAddRecExpr( getExtendAddRecStart<SCEVZeroExtendExpr>(AR, Ty, this, Depth + 1), getSignExtendExpr(...

...t; On Tue, Aug 8, 2017 at 12:58 PM, Friedman, Eli <efriedma at codeaurora.org> >>>> wrote: >>>>> >>>>> Oh, I see... yes, we do stupid things involving mutating NoWrap flags >>>>> after >>>>> a SCEV is created. (grep for setNoWrapFlags in ScalarEvolution.cpp.) >>>> >>>> >>>> That's really a compile time hack -- we defer some expensive tricks to >>>> prove nsw/nuw on an add recurrences to when we've been asked to >>>> sign/zero extend said add recurrence. >&...

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 save some compile time. Recently I'...

...eroExtendExpr()- > > > > // Cache knowledge of AR NW, which is propagated to this > > // AddRec. Negative step causes unsigned wrap, but it > > // still can't self-wrap. > > const_cast<SCEVAddRecExpr *>(AR)->setNoWrapFlags(SCEV::FlagNW); > > // Return the expression with the addrec on the outside. > > return getAddRecExpr( > > getExtendAddRecStart<SCEVZeroExtendExpr>(AR, Ty, this, > > Depth...

...anuary 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 cache 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 save some compile time. Recently I'...

On 8/8/2017 1:37 PM, Friedman, Eli wrote: > On 8/8/2017 10:22 AM, Geoff Berry via llvm-dev wrote: >> Hi all, >> >> I'm looking into resolving a FIXME in the LoopDataPrefetch (and FalkorMarkStridedAccesses) pass by marking both of these passes as preserving the ScalarEvolution analysis. Unfortunately, when this change is made, LSR will generate different code. One of the

...t; Would there be problems if we properly considered nuw/nsw flags when > unifying SCEVs? > > > There would be other consequences. For example, `(%x + %y)<nsw>` and `(%x > + %y)<nuw>` wouldn't compare equal for other simplifications, and all the > places that call setNoWrapFlags would have to be rewritten. It's probably > possible to come up with some workable design, but nobody has actually > tried it, so it's not clear how much work it would be to implement, or > whether it would improve the generated code overall. > > -Eli > > > On Wed,...

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 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 save some compile t...

...[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 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 save some compi...

...f 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 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 sav...

I'm not sure I understand the poison/undef/UB distinctions. But on this example: define i32 @func(i1 zeroext %b, i32 %x, i32 %y) { > entry: > %adds = add nsw i32 %x, %y > %addu = add nuw i32 %x, %y > %cond = select i1 %b, i32 %adds, i32 %addu > ret i32 %cond > } It is important to not propagate the nsw/nuw between the two SCEV expressions (which unification would

...endExpr()- > > > > // Cache knowledge of AR NW, which is propagated to this > > // AddRec. Negative step causes unsigned wrap, but it > > // still can't self-wrap. > > const_cast<SCEVAddRecExpr > *>(AR)->setNoWrapFlags(SCEV::FlagNW); > > // Return the expression with the addrec on the outside. > > return getAddRecExpr( > > getExtendAddRecStart<SCEVZeroExtendExpr>(AR, Ty, this, > > Depth...