similar to: Inferring nsw/nuw flags for increment/decrement based on relational comparisons

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

Sorry, the old title didn't make sense. > Hi, > > I have doubts on the following transformation in InstCombineAddSub.cpp. Is > it always safe to preserve NSW/NUW in this case? > > // If this is a 'B = x-(-A)', change to B = x+A. This preserves NSW/NUW. if (Value

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 instructions, which

On Aug 11, 2011, at 11:03 AM, Chris Lattner wrote: > > On Aug 11, 2011, at 5:17 AM, Florian Merz wrote: > >> 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

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

On Aug 11, 2011, at 5:17 AM, Florian Merz wrote: > 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

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 is a poison value if the truncated high

Hello everybody, currently I'm writing a thesis about compiler optimization techniques and I've choosen LLVM as a framework for implementing and testing my ideas. While reading the LLVM Language Reference Manual I noticed that the nuw and nsw keywords for the instructions add, sub and mul complicate reasoning about integer arithmetic for the purpose of my thesis somewhat.

Hi everybody, I saw that there are some instructions in the programs in which the flag nsw or nuw is placed. I wonder what rules does LLVM follows to put these flags in some instructions. Best, Douglas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110112/e696af22/attachment.html>

On Aug 11, 2011, at 11:32 AM, John McCall wrote: >> On Aug 11, 2011, at 5:17 AM, Florian Merz wrote: >> >>> 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 are permitted to turn 'sub nsw i32 %x, 1' into 'add nsw i32 %x, -1' nsw also has the same problem: sub nsw int_min, int_min is 0 but add nsw int_min, (-int_min) is poison -- Sanjoy

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, %0 br i1 %cmp, label %for.body, label

On Fri, Sep 30, 2011 at 7:59 AM, Tobias Grosser <tobias at grosser.es> wrote: > On 08/11/2011 02:56 PM, Duncan Sands wrote: >> 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,

Hi Duncan, Am Thursday, 11. August 2011, 15: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

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

Hello, If I run clang on the following code: void func(unsigned n) { > for (unsigned long x = 1; x < n; ++x) > dummy(x); > } I get the following llvm ir: define void @func(i32 %n) { > entry: > %conv = zext i32 %n to i64 > %cmp5 = icmp ugt i32 %n, 1 > br i1 %cmp5, label %for.body, label %for.cond.cleanup > for.cond.cleanup:

Hi, I am trying to understand the semantics of Instructions in llvm. Are the following instructions semantically same? * %add2 = add nsw i32 %add, %add1 %add3 = add i32 %add, %add1* Based on my understanding from the Language Reference Manual, I think they are different. But then why is the *gvn* pass detecting *%add3* as redundant and deleting it? Your views are appreciated. Rekha

On 08/11/2011 02:56 PM, Duncan Sands wrote: > 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

On 09/30/2011 04:46 PM, Duncan Sands wrote: >>> 3) If the destination type is signed, the value is unchanged if it >>> can be represented in the destination type (and bit-field >>> width); otherwise, the value is implementation-defined. >>> ---------------------------------------------------- >>> >>> 4.7.3 suggest to me, that the standard does

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/