similar to: [LLVMdev] Question about nsw and nuw flags

On Mon, Jan 24, 2011 at 3:01 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > On 01/24/2011 04:41 AM, Douglas do Couto Teixeira wrote: > >> Hi, >> >> Nick, thanks for the reply. >> I still have a problem: I only need to "clone" an Instruction, changing >> its type. That is, I would like to keep all characteristics of the old >> Instruction

Hi, Nick, thanks for the reply. I still have a problem: I only need to "clone" an Instruction, changing its type. That is, I would like to keep all characteristics of the old Instruction and create a new one only with a different type. I am trying create a new Instruction thus: %3 = add nsw i32 %1, %2 ; <i16> [#uses=2] //Old Instruction Value* Op0 = I->getOperand(0); Value*

Hi, guys, Thanks a lot for your help. As you know, I am trying to implement something to change the types of the instructions. And I chose the trunc's approach because it seems be simple. But I still have some problems and questions. Would be great if you can help me. I have used the results of my range analysis implementation to change the intermediate representation. I am using

Hello guys, I wonder how I can change the type of an integer variable. For instance, given the instruction "%3 = add i32 %1, %2" I would like to alter the instruction to "%3 = add i16 %1, %2". Is there any way to do this? Best wishes, Douglas -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 01/24/2011 04:41 AM, Douglas do Couto Teixeira wrote: > Hi, > > Nick, thanks for the reply. > I still have a problem: I only need to "clone" an Instruction, changing > its type. That is, I would like to keep all characteristics of the old > Instruction and create a new one only with a different type. Sure, but what about its operands? An "add" instruction

On 1/24/11 12:05 PM, Douglas do Couto Teixeira wrote: > > > On Mon, Jan 24, 2011 at 3:01 PM, Nick Lewycky <nicholas at mxc.ca > <mailto:nicholas at mxc.ca>> wrote: > > On 01/24/2011 04:41 AM, Douglas do Couto Teixeira wrote: > > Hi, > > Nick, thanks for the reply. > I still have a problem: I only need to "clone" an

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.

Hi guys, I have an analysis that is able to answer questions like this: given an integer variable, what is the interval of values that this variable can assume during the program's execution? I want to integrate this analysis into LLVM and it seems LVI (Lazy Value Info) is the best place to do this kind of stuff. Can someone give some hints about what I have to do to integrate my analysis

On 21 January 2011 12:56, Douglas do Couto Teixeira < douglasdocouto at gmail.com> wrote: > Hello guys, > > I wonder how I can change the type of an integer variable. For instance, > given the instruction "%3 = add i32 %1, %2" I would like to alter the > instruction to "%3 = add i16 %1, %2". Is there any way to do this? > No. Instead you create a new

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

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

On Wed, Mar 23, 2011 at 6:24 PM, John Criswell <criswell at illinois.edu> wrote: > > > On 3/23/11 8:06 AM, Douglas do Couto Teixeira wrote: > > > > the execution of a program. Thus, for each integer variable, a range > > analysis determines its lower and upper limits. A very simple range analysis > > > would, for instance, map each variable to the limits

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

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

Dear LLVM community, I would like to contribute to LLVM in the Google Summer of Code project. My proposal is listed below. Please let me know your comments. Adding Range Analysis to LLVM Abstract The objective of this work is patch our implementation of range analysis into LLVM. I have a running implementation of range analysis in LLVM, but it is not currently part of the main distribution. I

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