similar to: [LLVMdev] Removing nuw and nsw

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

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?

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 integer overflows on

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

According to 6.3.1.3/3 of the C standard (I didn't check C++): "3 Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised." I *think* that means that IF a signal is raised then the signal raised could be one that you can't guarantee to be able to return from

On 07/05/2017 03:10 PM, Alexandre Isoard wrote: > Ah, ok. I read it wrong. In *neither* case it is UB. > > Hum, can an implementation define it as UB? :-) Nope :-) The only case I've thought of where we could add these for C++ would be on conversions to (most) enums (because they used signed underlying types and the out-of-bounds mapping won't generally be one of the allowed

Is that why we do not deduce +<nsw> from "add nsw" either? Is that an intrinsic limitation of creating a context-invariant expressions from a Value* or is that a limitation of our implementation (our unification not considering the nsw flags)? On Wed, Aug 15, 2018 at 12:39 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 12:21 PM, Alexandre Isoard via

Ok. To go back to the original issue, would it be meaningful to add a SCEVUMax(0, BTC) on the final BTC computed by SCEV? So that it does not use "negative values"? On Wed, Aug 15, 2018 at 2:40 PM Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/15/2018 2:27 PM, Alexandre Isoard wrote: > > I'm not sure I understand the poison/undef/UB distinctions. >

Hi, Even if there are no ways in which a *frontend* can produce nsw truncs, it may still be useful to have if optimization passes can usefully attach nsw to truncates (after proving the truncates don't "overflow"). For instance in %a = ashr i64 %v, i32 33 %t = trunc %a to i32 the trunc can be marked nsw. However, the burden of proof here is to show that we can do some useful

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

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

Hi Sanjoy, thanks for your thoughts on this. On Sat, Jun 27, 2015 at 12:16 AM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > > First of all, going by the "poison causes UB only when observed", SCEV > does not do the right thing currently: [...] > > That seems like a bug? There's also bug 23527 for GEP. Sounds like there might be more such bugs. One

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

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

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:

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 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

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

Hi everyone, 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 the following, please see the bug report for more detail: > 1. If (X s< Y), then both X + 1 and Y - 1 are nsw. > 2.