similar to: analysis based on nonnull attribute

----- Original Message ----- > From: "Sanjay Patel via llvm-dev" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, December 14, 2016 3:47:03 PM > Subject: [llvm-dev] analysis based on nonnull attribute > Does the nonnull parameter attribute give us information about > subsequent uses of that value

On Wed, Dec 14, 2016 at 2:51 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ------------------------------ > > *From: *"Sanjay Patel via llvm-dev" <llvm-dev at lists.llvm.org> > *To: *"llvm-dev" <llvm-dev at lists.llvm.org> > *Sent: *Wednesday, December 14, 2016 3:47:03 PM > *Subject: *[llvm-dev] analysis based on nonnull attribute

----- Original Message ----- > From: "Sanjay Patel" <spatel at rotateright.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Wednesday, December 14, 2016 4:03:40 PM > Subject: Re: [llvm-dev] analysis based on nonnull attribute > On Wed, Dec 14, 2016 at 2:51 PM, Hal Finkel <

I think what Sanjay is getting at is that it's not an integer, it's still a pointer - but it's not clear where information about non-nullness of the pointer should be propagated to. In this particular case, since the def of %x in the caller is also an argument, we could propagate it to the def directly, e.g. define i1 @foo(i32* nonnull %x) { %y.i = load i32, i32* %x ; inlined,

----- Original Message ----- > From: "Michael Kuperstein" <michael.kuperstein at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Sanjay Patel" <spatel at rotateright.com>, "llvm-dev" > <llvm-dev at lists.llvm.org>, "Michael Kuperstein" <mkuper at google.com> > Sent: Thursday, December 15, 2016

By the way, I've been wondering - why can we only attach !nonnull and !range to loads (for both) and call/invoke (for !range)? I mean, those are all instructions you can't do dataflow through - intraprocedurally, w/o memoryssa - but why only these instructions? Why not allow annotating any pointer def with !nonnull and any integer def with !range? Sure, that's redundant w.r.t

The general idea to date has been only "sources" get annotations. If there's something we fundamentally *can't* analyze through, that's where we annotate. We try not to use annotations for places where we could have but didn't. e.g. call metadata/attributes allow us to model external calls, load metadata allow us to model frontend knowledge of external memory

Calling an instruction a "source" is basically another way to say "we can't dataflow through this". What I'm trying to say is that this is not really a property of the instruction type. I agree we should be adding annotations sparingly - that is, we should not annotate something we can infer. But that's a semantic property, so I don't really see why that means

On 12/16/2016 11:37 AM, Michael Kuperstein wrote: > Calling an instruction a "source" is basically another way to say "we > can't dataflow through this". > > What I'm trying to say is that this is not really a property of the > instruction type. > I agree we should be adding annotations sparingly - that is, we should > not annotate something we

On Fri, Dec 16, 2016 at 11:49 AM, Philip Reames <listmail at philipreames.com> wrote: > > > On 12/16/2016 11:37 AM, Michael Kuperstein wrote: > > Calling an instruction a "source" is basically another way to say "we > can't dataflow through this". > > What I'm trying to say is that this is not really a property of the > instruction

Based on the earlier comments in this thread and the existence of a transform that adds 'nonnull' to callsite params, I have proposed a patch to extend nonnull to a parent function: https://reviews.llvm.org/D27855 ...but given today's comments about inferring the analysis rather than making it part of the IR, this might be the wrong approach? On Fri, Dec 16, 2016 at 12:49 PM, Philip

>>> In this particular case, since the def of %x in the caller is also an argument, we could propagate it to the def directly, e.g. define i1 @foo(i32* nonnull %x) { %y.i = load i32, i32* %x ; inlined, still known to be nonnull >>> For propagation of non-nullity to the argument, don't you need value propagation or backward all dataflow analysis? IE. define i1 @foo(i32*

Hi, I have come across a couple of cases where the code generated after CodeGenPrepare pass has "br i1 false .." with both true and false conditions preserved and this propagates further and remains the same in the final assembly code/executable. In CodeGenPrepare::runOnFunction, ConstantFoldTerminator (which handles the br i1 false condition) is called only once and if after the

While looking at what llvm writes for this testcase, I noticed that there is one redundant operation in resulting assembly. The second 'cmp' operation there is essentially identical to the first one, with reversed order of arguments. Therefore, it is not needed. This testcase is a simple integer comparison routine, similar to what qsort would take to sort an integer array. I think

> If we don't care about trying to optimize out overflow checks in > InstCombine, I'd go with moving the complexity to CGP. I think instcombine should optimize out overflow checks (as it does today) without introducing _with_overflow calls. Are there reasons why such an approach would not work? > However, I think > InstCombine is doing the right thing here by forming these.

Hello, while writing a new LLVM backend I have observed that in some cases the optimizer produces an "icmp sgt i32 %a, 0" where I would have expected an "icmp ugt i32 %a, 0". For example when I feed "opt -O3 -S ..." (LLVM 2.9, Windows) with ------------------------------------------------------------------------ target datalayout = "E-p:32:32:32"

Hi, Can any llvm pass change simple return branch into select/return pair? For example: define i10 @mod_N(i10 zeroext %a) zeroext { entry: %tmp2 = icmp ugt i10 %a, -400 ; <i1> [#uses=1] br i1 %tmp2, label %cond_true, label %return cond_true: ; preds = %entry %tmp5 = add i10 %a, 400 ; <i10> [#uses=1] ret i10 %tmp5 return: ; preds = %entry ret

Icmp sgt is correct. Note that "ugt x, 0" is the same as "x != 0" which is not what you want. -Chris On Aug 1, 2011, at 9:11 AM, Jonas Gefele <llvm.org at schrieb.de> wrote: > Hello, > > while writing a new LLVM backend I have observed that in some cases the > optimizer produces an "icmp sgt i32 %a, 0" where I would have expected an >

Hi, Look at the following code: Look at the following C code seqence: unsigned char mainGtU ( unsigned int i1, unsigned int i2, unsigned char* block) { unsigned char c1, c2; c1 = block[i1]; c2 = block[i2]; if (c1 != c2) return (c1 > c2); i1++; i2++; c1 = block[i1]; c2 = block[i2]; if (c1 != c2) return (c1 > c2); i1++; i2++; .. ..

Hi, This message is a result of a discussion of backend optimization for sub(max) pattern(https://reviews.llvm.org/D25987), which can be either converted to unsigned min-max or unsigned saturation instruction(if the target supports it). Currently these versions of the code produce different IR(and we need to manage both types in backend): (1.16) void foo(unsigned short *p, unsigned short max,