similar to: [LLVMdev] nsw/nuw for trunc

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

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

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

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,

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

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

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

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

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

>> 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 not define a result for >> '(signed char)

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

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:

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