similar to: [LLVMdev] Does lli know how to interpret arithmetic overflow intrinsics?

I understand that overflow behaviours can be different on different hardware. But can we write .ll implementation of these overflow intrinsics, e.g. assuming 0..255 as value range for unsigned i8 ? - sanjiv On Thu, May 5, 2011 at 11:18 AM, Sanjiv <llvmdev at gmail.com> wrote: > Do we have a .ll test cases for arithmetic overflow intrinsics that lli can > execute and report any

Hi Sanjay, Some time ago you implemented a sext(add_nsw(x, C)) --> add(sext(x), C_sext) transformation in X86ISelLowering https://reviews.llvm.org/D13757 Is there any reason why this transformation is limited to sexts and doesn’t support zexts? Thanks, Artur -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Sanjay, On 19 Jul 2016, at 18:54, Sanjay Patel <spatel at rotateright.com<mailto:spatel at rotateright.com>> wrote: Hi Artur - I don't think there's any reason to limit the transform to sexts only; that's just the case that was apparent in https://llvm.org/bugs/show_bug.cgi?id=20134 , so I limited it to that pattern. It's probably worth noting that I'm

My gut tells me that Hal is right, and we should prefer zexts as long as the select boils down to one instruction, but let me go against my intuition and try to list two reasons why we should prefer selects: * Folding operations into selects: it is trivial to transform f(select X, Const0, Const1) to select X, f(Const0), f(Const1), while doing that can be difficult for zexts. define

In my language there are a lot of i16 definitions, but almost all of the time they are upgraded to i32 because my add operations only happen on i32. So to be representative to my language definition, I have a lots of Sext/Zext and Truncs pretty much every time I add or subtract. As soon as I pass through InstCombine things look much nicer, all the upcasts and downcasts go away, but my test cases

I am testing vectorization on the following test case: float x[1024], y[1024]; void myloop1() { for (long int k = 0; k < 512; k++) { x[2*k] = x[2*k]+y[k]; } } Vectorization failed due to "unsafe dependent memory operation". I traced the LoopAccessAnalysis.cpp and found the reason is the NoWrapFlag for SCEVAddRecExpr is not set and consequently the

[+Arnold] > On Jun 10, 2015, at 1:29 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > [+CC Andy] > >> Can anyone familiar with ScalarRevolution tell me whether this is an >> expected behavior or a bug? > > Assuming you're talking about 2*k, this is a bug. ScalarEvolution > should be able to prove that {0,+,4} is <nsw> and

On 01/27/2015 09:38 PM, Sanjoy Das wrote: >> if the definition of NUW is that zext-ing the result is equivalent to >> zext-ing the inputs and doing the operation at a higher bitwidth (my >> understanding), then %m and %n cannot hold those values, that would violate >> the NUW flag. > The problem to solve is adequately defining "cannot hold". In the >

On Tue, Jan 27, 2015 at 7:23 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi David, > > I spent some time thinking about poison semantics this way, but here > is where I always get stuck: > > Consider the IR fragment > > %x = zext i32 %maybe_poison to i64 > %y = lshr i64 %x 32 > %ptr = gep %global, %y > store 42 to %ptr > > If

> I don't think your example is actually problematic. The original program > before your transformation *executed* undefined behavior in the form of '%x > = add nuw i32 %m, %n' with "%m = %n = 2^32-1 (a.k.a INT_MAX)". If I I was trying to show why the rule "signed overflow is undefined behavior" is problematic w.r.t. hoisting arithmetic by repeating an

I have another round of questions about IR select canonicalizations. For the purity of this quiz, please disregard prior knowledge of how this is handled by instcombine or how this is lowered by your favorite target...of course we'll fix it. :) Some answers in the links below if you do want to know. Which, if any, of these is canonical? 1. Is a zext simpler than a select? a. define i32

On Nov 12, 2009, at 11:29 PM, John McCall wrote: >> sext/zext/trunc are very nice for the optimizer, we should keep >> them. It means that the optimizer doesn't have to check that the >> input to a sext is bigger or smaller than the result, for example. >> Code that cares (e.g. instcombine) really likes this. > > We could just say that code has undefined

Hi all, I am trying to run LLI on an optimized bitcode file in interpreted mode, and I get the following error message: LLVM ERROR: Code generator does not support intrinsic function 'llvm.usub.with.overflow.i32'! As the error message indicates, this intrinsic is not supported (lib/CodeGen/IntrinsicLowering.cpp). Is there any way that I can get the interpreter to work across this

I'm looking at the output of memcmp() expansion (D34904), and I noticed that there are many ways to produce the common positive/zero/negative comparison result in IR. For the following 6 functionally equivalent C source functions, we produce 6 different versions of IR which leads to 6 different asm outputs for x86. Which of these should we choose as canonical IR form? 1. Two selects int

Hi, As my target supports signed / unsigned interpretation of operands, I was a bit startled to find that the LLVM I/R does not express this info of the integer operands. I want to create an eg unsigned mul if the operands are unsigned, using an intrinsic. I find that with -g, metadata is generated which seems to convey this information. Is it safe to base this type of transformation on the

John McCall wrote: > I didn't realize that an identity zext was actually invalid IR. That > seems like it probably causes more trouble than it's worth. > > Anyway, I suspect the question is whether you would rather break these > invariants (which are probably not critical for most optimizations) or > slowly accumulate duplicate code paths in every pass that looks at

Chris Lattner wrote: > On Nov 12, 2009, at 11:29 PM, John McCall wrote: >>> sext/zext/trunc are very nice for the optimizer, we should keep >>> them. It means that the optimizer doesn't have to check that the >>> input to a sext is bigger or smaller than the result, for example. >>> Code that cares (e.g. instcombine) really likes this. >>

clang generates llvm.memcpy.* intrinsics for our port. Now we are linking a .bc version of the standard library. Do we have to include a version of these intrinsics in the .bc librrary? If yes, do we have some already written version? Or do we have to leave them for llc to convert them in to memcpy and then provide an binary version of lib with these functions ? - Sanjiv

> On Jun 10, 2015, at 6:17 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > I'm not sure if inbounds can be used to prove <nuw>. If an object > %OBJ is allocated at address -1 then "gep inbounds %OBJ 1" is not > poison, but the underlying computation unsigned-overflows. I think that this should yield poison per langref because the signed

Hi, I'm trying to implement the TTI hooks for AMDGPU to avoid unrolling loops for operations with huge expansions (i.e. integer division). The values that are ultimately reported by opt -cost-model -analyze (the actual cost model tests) seem to not matter for this. The huge cost I've assigned division doesn't prevent the loop from being unrolled, because it isn't actually