search for: cmp5

...ICmp = dyn_cast<ICmpInst>(&V); > assert(ICmp && "Only ICmpInst of constant as condition supported!"); ... > > The code it chokes on looks like this (see below). The problem is this OR-ed > compare result: > > %cmp3 = icmp sgt i32 %j.0, 2 > %cmp5 = icmp eq i32 %j.0, 1 > %or.cond13 = or i1 %cmp3, %cmp5 > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< == > Value V > > > My question - is this a bug or a (missing) feature? .....

...align 1 %add.ptr = getelementptr inbounds i8, i8* %d.addr.0, i64 8 %3 = bitcast i8* %add.ptr to i64* %4 = load i64, i64* %3, align 1 store i64 %4, i64* %2, align 1 %add.ptr3 = getelementptr inbounds i8, i8* %d.addr.0, i64 6 %add.ptr4 = getelementptr inbounds i8, i8* %h.addr.0, i64 6 %cmp5 = icmp ult i8* %add.ptr4, %p3 br i1 %cmp5, label %while.cond, label %return while.end: ; preds = %while.cond tail call void @_Z1fv() unreachable return: ; preds = %while.body ret i8* %p3 } -----------------...

...d.addr.0, i64 8 >> %3 = bitcast i8* %add.ptr to i64* >> %4 = load i64, i64* %3, align 1 >> store i64 %4, i64* %2, align 1 >> %add.ptr3 = getelementptr inbounds i8, i8* %d.addr.0, i64 6 >> %add.ptr4 = getelementptr inbounds i8, i8* %h.addr.0, i64 6 >> %cmp5 = icmp ult i8* %add.ptr4, %p3 >> br i1 %cmp5, label %while.cond, label %return >> >> while.end: ; preds = %while.cond >> tail call void @_Z1fv() >> unreachable >> >> return:...

...m alloca point" = bitcast i32 0 to i32 %arrayidx3 = getelementptr inbounds [2048 x i32], [2048 x i32]* %A, i64 0, i64 1024 %0 = load i32, i32* %arrayidx3, align 16 %arrayidx4 = getelementptr inbounds [2048 x i32], [2048 x i32]* %B, i64 0, i64 1024 %1 = load i32, i32* %arrayidx4, align 16 %cmp5 = icmp eq i32 %0, %1 %conv = zext i1 %cmp5 to i32 %call = call i32 (i32, ...) bitcast (i32 (...)* @assert to i32 (i32, ...)*)(i32 %conv) #2 ret i32 0}* It is my understanding that in the original C code the assert would never fail, however in the optimized IR the assert might fail. I tried usin...

...t; > assert(ICmp && "Only ICmpInst of constant as condition supported!"); > ... > > > > The code it chokes on looks like this (see below). The problem is this > OR-ed > > compare result: > > > > %cmp3 = icmp sgt i32 %j.0, 2 > > %cmp5 = icmp eq i32 %j.0, 1 > > %or.cond13 = or i1 %cmp3, %cmp5 > > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< == > > Value V > > > > > > My question - is this a bug...

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: ; preds = %for.body, > %entry > ret void > for.body: ; preds = %entry, > %for.body > %x.06 = phi i64 [...

On 07/01/2013 09:41 AM, Renato Golin wrote: > On 1 July 2013 02:02, Chris Matthews <chris.matthews at apple.com> wrote: > >> One thing that LNT is doing to help “smooth” the results for you is by >> presenting the min of the data at a particular revision, which (hopefully) >> is approximating the actual runtime without noise. >> > > That's an

...un 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: ; preds = %for.body, >> %entry >> ret void >> for.body: ; preds = %entry, >> %for.body &...

Hi, I often find myself staring at IR and wanting to look at the C source code it corresponds to. To do so, I look up the debug identifier for the given IR line, scroll to the bottom of the IR file to find the debug identifier, look at the debug location (source and column), and then look at the source file. Too many steps. What would be great is a tool that took two files, i.e., a .c file and a

On 1 July 2013 02:02, Chris Matthews <chris.matthews at apple.com> wrote: > One thing that LNT is doing to help “smooth” the results for you is by > presenting the min of the data at a particular revision, which (hopefully) > is approximating the actual runtime without noise. > That's an interesting idea, as you said, if you run multiple times on every revision. On ARM,

...id 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: ; preds = %for.body, >>> %entry >>> ret void >>> for.body: ; preds = %entry,...

...(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: ; preds = %for.body, >>>> %entry >>>> ret void >>>> for.body:...

...load i16* %arrayidx.i.i, align 2, !tbaa !5 %and.i.i = and i16 %3, 32767 %cmp.i.i = icmp eq i16 %and.i.i, 32767 %4 = load i16* %arraydecay, align 2, !tbaa !5 br i1 %cmp.i.i, label %for.cond.preheader.i.i, label %if.end.i for.cond.preheader.i.i: ; preds = %if.end %cmp5.i.i = icmp eq i16 %4, 0 br i1 %cmp5.i.i, label %for.inc.i.i, label %eisneg.exit for.inc.i.i: ; preds = %for.cond.preheader.i.i %incdec.ptr.i.i = getelementptr inbounds [13 x i16]* %e, i32 0, i32 1 %5 = load i16* %incdec.ptr.i.i, align 2, !tbaa !5 %cmp5....