similar to: [LLVMdev] "icmp sgt" when it should be "ugt" ?

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 Chris, > Icmp sgt is correct. while ugt would be wrong, I think sgt is too! For example, suppose %buf is 0 and %bufLen is ~0U. Then %add.ptr is ~0U, and %cmp is true, so control branches to %if.then. However in the optimized version %cmp is false and control branches to %if.end. The GEP does have an inbounds attribute, I'm not sure if that is relevant here. Ciao, Duncan. Note

Hi Eli, >>> Icmp sgt is correct. >> >> while ugt would be wrong, I think sgt is too! >> >> For example, suppose %buf is 0 and %bufLen is ~0U. Then %add.ptr is ~0U, and >> %cmp is true, so control branches to %if.then. However in the optimized version >> %cmp is false and control branches to %if.end. >> >> The GEP does have an inbounds

On Aug 2, 2011, at 8:53 AM, Duncan Sands wrote: > Hi Eli, > >>>> Icmp sgt is correct. >>> >>> while ugt would be wrong, I think sgt is too! >>> >>> For example, suppose %buf is 0 and %bufLen is ~0U. Then %add.ptr is ~0U, and >>> %cmp is true, so control branches to %if.then. However in the optimized version >>> %cmp is

On Tue, Aug 2, 2011 at 3:47 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Chris, > >> Icmp sgt is correct. > > while ugt would be wrong, I think sgt is too! > > For example, suppose %buf is 0 and %bufLen is ~0U.  Then %add.ptr is ~0U, and > %cmp is true, so control branches to %if.then.  However in the optimized version > %cmp is false and control branches

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

Hi, Recently 10% performance regression on an important benchmark showed up after we integrated https://reviews.llvm.org/rL318299. The analysis showed that rL318299 triggered loop rotation on an multi exits loop, and the loop rotation introduced code layout issue. The performance regression is a side-effect of rL318299. I got two testcases a.ll and b.ll attached to illustrate the problem. a.ll

On Mon, Dec 18, 2017 at 5:46 PM Xinliang David Li <davidxl at google.com> wrote: > The introduction of cleanup.cond block in b.ll without loop-rotation > already makes the layout worse than a.ll. > > > Without introducing cleanup.cond block, the layout out is > > entry->while.cond -> while.body->ret > > All the arrows are hot fall through edges which is

We have several optimizations in InstCombine for bitwise logic ops (and/or/xor) that fail to handle compare patterns with the equivalent bitwise logic. Example: define i8 @or_and_not(i8 %a, i8 %b) { %nota = xor i8 %a, -1 %and = and i8 %nota, %b %res = or i8 %and, %a ret i8 %res } define i1 @or_and_cmp_not(i32 %a, i32 %b, i1 %c) { %cmp = icmp sgt i32 %a, %b %cmp_inv = icmp sle i32 %a,

The Samba ports are not filtered. The firewall is between STG-DC and SAMBADC (both of them sync correctly). The sync problems happen in VIG-DC3, which is behind the same firewall of STG-DC. Here's nmap output (SAMBADC is 172.16.50.9): root at vig-dc3:~# nmap -Pn 172.16.50.9 Starting Nmap 7.93 ( https://nmap.org ) at 2024-05-23 08:22 UTC Nmap scan report for SAMBADC.ugt.ldap (172.16.50.9)

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,

Hi, I compiled the following code on a Sparc machine, basically it produce different results than a X86 machine. ------------------------------------------------------------------------------------------------------------------- ; MduleID = '<stdin>' target datalayout =

On 5/16/2017 6:30 AM, Sanjay Patel wrote: > Thanks for posting this question, Julia. > > I had a similar question about a signed min/max variant here: > http://lists.llvm.org/pipermail/llvm-dev/2016-November/106868.html > > The 2nd version in each case contains a canonical max/min > representation in IR, and this could enable more IR analysis. > A secondary advantage is

Hi, > target datalayout = > "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" > target triple = "i386-pc-linux-gnu" if you are using this target data layout and triple on a Sparc machine, I'm not surprised you get wrong results. Ciao, Duncan. > > @P = global i32 1 > @dP =

Hi, On 10/01/13 10:56, Alexandru Ionut Diaconescu wrote: > Hello everyone ! > > In my pass I inspect the penultimate instruction from every basic block in > runOnFunction(). I am interested in ICMP instructions only. > > |if(BB->size()>1) > if(last->getPrevNode()) > { > previous = last->getPrevNode(); > ok=1; > } > |

Hi guys, Thanks for the input. However, it seems that the code still produces the wrong output on a Sparc machine. My current llvm_print.bc code is: -------------------------------------------------------------------------------------------------- ; MduleID = '<stdin>' target datalayout =

Hi, On Thu, Sep 15, 2011 at 3:15 PM, Christine Cheng <clcheng at stanford.edu> wrote: > Hi guys, > > Thanks for the input. However, it seems that the code still produces the > wrong output on a Sparc machine. > > My current llvm_print.bc code is: > -------------------------------------------------------------------------------------------------- > ; MduleID =

Hi Duncan, Thanks for the reply! There is no LLVM on the Sparc machine so I cannot compile my code there into .s file. How shall I modify the target data layout and triple so it works on Sparc? Basically I got these from compiling C code using llvm-gcc. Best, Christine On Thu, Sep 15, 2011 at 10:20 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi, > > > target datalayout =

Hi, everybody! I have been using samab on Debian for years and I have recently migrated my file server from version 3.0.14a-3sarge2 to 3.0.24-6etch4. One or our applications stores its data in a shared folder. This data is distributed in over 29000 files of about 1k-40k and is so much slower when it runs on the new server. I have thoroughly revised both smb.conf files, but can't see

Hello everyone ! In my pass I inspect the penultimate instruction from every basic block in runOnFunction(). I am interested in ICMP instructions only. if(BB->size()>1) if(last->getPrevNode()) { previous = last->getPrevNode(); ok=1; } I want to get the operands of previous, which is of type Instruction*. Due tests based on getNumOperands, ICMP has 2 (as