search for: nuw

...e: (annotated with SCEV) define void @func([132 x [140 x float]]* nocapture dereferenceable(73920)) local_unnamed_addr #0 { br label %2 ; <label>:2: ; preds = %11, %1 ; loop<%2> at depth 1 with exact backedge-taken count of 131 ; %12 = {1,+,1}<nuw><nsw><%2> ; %3 = {0,+,1}<nuw><nsw><%2> %3 = phi i64 [ 0, %1 ], [ %12, %11 ] br label %4 ; <label>:4: ; preds = %4, %2 ; loop<%4> at depth 2 with exact backedge-taken count of 139 ; %5 = {0,+,1}<nuw><nsw&...

...rote: > On 8/15/2018 2:27 PM, Alexandre Isoard wrote: > > 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 do today, can I consider that a bug or > is it a feature?). > > &g...

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 do today, can I consider that a bug or is it a feature?). So we work-around it by not informing SCEV of t...

...; preds = %for.body, >> %entry >> ret void >> for.body: ; preds = %entry, >> %for.body >> %x.06 = phi i64 [ %inc, %for.body ], [ 1, %entry ] >> tail call void @dummy(i64 %x.06) #2 >> %inc = add nuw nsw i64 %x.06, 1 >> %exitcond = icmp eq i64 %inc, %conv >> br i1 %exitcond, label %for.cond.cleanup, label %for.body >> } > > > Over which, SCEV will provide the following analysis: > > Printing analysis 'Scalar Evolution Analysis' for function 'func...

Hello, >From [1], trunc does not seems to have a nsw/nuw attribute. Is it possible to have that? Or do we have that and it is not up-to-date? The definition would be: If the nuw keyword is present, the result value of the trunc is a poison value if the truncated high order bits are non-zero. If the nsw keyword is present, the result value of the trunc...

...nd.cleanup: ; preds = %for.body, > %entry > ret void > for.body: ; preds = %entry, > %for.body > %x.06 = phi i64 [ %inc, %for.body ], [ 1, %entry ] > tail call void @dummy(i64 %x.06) #2 > %inc = add nuw nsw i64 %x.06, 1 > %exitcond = icmp eq i64 %inc, %conv > br i1 %exitcond, label %for.cond.cleanup, label %for.body > } Over which, SCEV will provide the following analysis: Printing analysis 'Scalar Evolution Analysis' for function 'func': > Classifying expression...

I've been doing some digging in this area (scev, wrapping arithmetic), learning as much as I can, and have reached a point where I'm fairly confused about the semantics of nuw in scalar evolution expressions. Consider the following program: define void @foo(i32 %begin) { entry: br label %loop loop: %idx = phi i32 [ %begin, %entry ], [ %idx.dec, %loop ] %idx.dec = sub nuw i32 %idx, 1 %exit.condition = icmp eq i32 %idx.dec, 0 br i1 %exit.condition, label %loo...

Hi, > Hi Alexandre, > > LLVM currently doesn't have trunc nsw/nuw, no. > Which frontend would emit such instructions? Any application in mind? > Just asking because if no frontend could emit those, then the motivation to > add nsw/nuw support to trunc would be very low I guess. I think the clang frontend could use that to allow better static analysis of...

On Aug 11, 2011, at19:34, John McCall wrote: > On Aug 11, 2011, at 7:31 AM, Florian Merz wrote: > > If we had nsw and nuw flags for truncations we'd know when to check for > > this kind of overflow and when not. The compiler likely doesn't need > > these flags and can still ignore them, for us they would be useful. > > Duncan's point is that this is totally different from the semantics o...

On Aug 11, 2011, at 7:31 AM, Florian Merz wrote: > If we had nsw and nuw flags for truncations we'd know when to check for this > kind of overflow and when not. The compiler likely doesn't need these flags and > can still ignore them, for us they would be useful. Duncan's point is that this is totally different from the semantics of nsw/nuw on other...

...; preds = %entry, %while.body %i.010 = phi i32 [ 0, %entry ], [ %inc, %while.body ] %arrayidx = getelementptr inbounds [10 x i32], [10 x i32]* @buffer, i32 0, i32 %i.010 %0 = load i32, i32* %arrayidx, align 4, !tbaa !2 %cmp1 = icmp ne i32 %0, -559038737 %inc = add nuw nsw i32 %i.010, 1 %cmp11 = icmp eq i32 %i.010, 0 %cmp = or i1 %cmp11, %cmp1 br i1 %cmp, label %while.body, label %while.end while.end: ; preds = %while.body %arrayidx2 = getelementptr inbounds [10 x i32], [10 x i32]* @buffer, i32 0, i32 %i.010 %1 =...

David/All, Just a quick question about NSW/NUW bits, if you've got a second. I noticed you've been doing a little work on this as of late. I have a bit of code that looks like the following: %indvars.iv.next = add nuw nsw i64 %indvars.iv, 1 %2 = add i64 %indvars.iv.next, -1 %tmp = trunc i64 %2 to i32 %cmp = icmp slt i32 %tmp,...

...5:56:22 schrieb Duncan Sands: > Hi Florian, > > > we'd like to be able to check for loss of information in trunc operations > > in our LLVM-based bounded model checker [1]. For this it is important if > > the trunc was on a signed or unsigned integer, so we need nsw and nuw > > flags for this. Would you accept a patch that adds these flags to LLVM > > (and possibly clang)? > > nsw/nuw don't mean signed/unsigned arithmetic. They mean that > signed/unsigned overflow in the operation results in undefined behaviour. > As far as I know, trunc...

...ng 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 root causes seems to be that SCEV will return different nsw/nuw flags for the same Value, depending on what order the SCEVs are computed, due to the fact that the SCEV object unique-ing doesn't take the nsw/nuw flags into account. Since LoopDataPrefetch computes SCEVs in a different order than LSR, the nsw/nuw flags seen by LSR will differ based on whe...

....body >> %i.010 = phi i32 [ 0, %entry ], [ %inc, %while.body ] >> %arrayidx = getelementptr inbounds [10 x i32], [10 x i32]* @buffer, i32 0, >> i32 %i.010 >> %0 = load i32, i32* %arrayidx, align 4, !tbaa !2 >> %cmp1 = icmp ne i32 %0, -559038737 >> %inc = add nuw nsw i32 %i.010, 1 >> %cmp11 = icmp eq i32 %i.010, 0 >> %cmp = or i1 %cmp11, %cmp1 >> br i1 %cmp, label %while.body, label %while.end >> >> while.end: ; preds = %while.body >> %arrayidx2 = getelementptr inbounds [10 x i3...

On Wed, Jul 5, 2017 at 3:59 PM, Hal Finkel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 07/04/2017 01:41 AM, Dr.-Ing. Christoph Cullmann via llvm-dev wrote: > >> Hi, >> >> Hi Alexandre, >>> >>> LLVM currently doesn't have trunc nsw/nuw, no. >>> Which frontend would emit such instructions? Any application in mind? >>> Just asking because if no frontend could emit those, then the motivation >>> to >>> add nsw/nuw support to trunc would be very low I guess. >>> >> I think the clang...

...olving 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 root causes seems to be that SCEV will return different nsw/nuw flags for the same Value, depending on what order the SCEVs are computed, due to the fact that the SCEV object unique-ing doesn't take the nsw/nuw flags into account. Since LoopDataPrefetch computes SCEVs in a different order than LSR, the nsw/nuw flags seen by LSR will differ based on whether...

...king at %x. > > > > > > I agree, this makes sense. > > > >> > >> Given that, the store in the above > >> fragment is not undefined behavior even if %maybe_poison is poison. > >> However, this means if "%maybe_poison" is "add nuw %m, %n" it cannot > >> be optimized to "add nuw (zext %m) (zext %n)" since that will change > >> program behavior in an otherwise well-defined program. > > > > > > Hmm, I'm not so sure this is right. > > > > Are we talking about tra...

On Tue, Jan 27, 2015 at 8:32 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > > > Correct me if I am wrong but we are talking about transforming: > > %maybe_poison = add nuw i32 %a, %b > > %x = zext i32 %maybe_poison to i64 > > %y = lshr i64 %x 32 > > > > To: > > %za = zext i32 %a to i64 > > %zb = zext i32 %b to i64 > > %x = add nuw i64 %za, %zb > > %y = lshr i64 %x 32 > > > > ? > > &gt...

Hi everyone, we'd like to be able to check for loss of information in trunc operations in our LLVM-based bounded model checker [1]. For this it is important if the trunc was on a signed or unsigned integer, so we need nsw and nuw flags for this. Would you accept a patch that adds these flags to LLVM (and possibly clang)? Regards, Florian [1] http://baldur.iti.uka.de/llbmc/