search for: cfgsimplify

...instruction combine cannot handle the instruction %4 = select i1 %tobool.i, metadata !12, metadata !10 generated by the phase of CFG simplification and the compiler generates an assertion failure. I wonder whether this is valid LLVM IR: %4 = select i1 %tobool.i, metadata !12, metadata !10 Before CFGSimplify cond.true.i: ; preds = %entry %add.ptr.i = getelementptr inbounds i8, i8* %2, i64 8 %left_.i.i = bitcast i8* %add.ptr.i to i32** %3 = call i32** @llvm.fakeload.p0p0i32(i32** %left_.i.i, metadata !8) #6 br label %_ZN1G7insert_Ev.exit cond.false.i:...

...:llvm-dev-bounces at lists.llvm.org] > On Behalf Of Lin, Jin via llvm-dev > Subject: [llvm-dev] Is the instruction %4 = select i1 %tobool.i, metadata !12, metadata !10 legal? > I wonder whether this is valid LLVM IR: > %4 = select i1 %tobool.i, metadata !12, metadata !10 > Before CFGSimplify > cond.true.i:                                      ; preds = %entry >  %add.ptr.i = getelementptr inbounds i8, i8* %2, i64 8 >  %left_.i.i = bitcast i8* %add.ptr.i to i32** >  %3 = call i32** @llvm.fakeload.p0p0i32(i32** %left_.i.i, metadata !8) #6  br label %_ZN1G7insert_Ev.exit >...

...r doing instcombine style optimizations within the loop as well, but that's less clear to me. > All trivial LICM done. By this I mean LICM which does not require aliasing or speculation safety logic. This is Loop::makeInvariant. > All trivial branches discharged. By this I mean both CFGSimplify style elimination of constant branch conditions, but also CVP, KnownBits, and SCEV. (Today, this is often true on entry to a loop pass manager, but is not upheld as passes run.) > To be clear, the above list is aspirational. We definitely don't do all of the above today. :) > > Phi...

...oing instcombine style optimizations within the loop as well, but that's less clear to me. * All trivial LICM done.  By this I mean LICM which does not require aliasing or speculation safety logic.  This is Loop::makeInvariant. * All trivial branches discharged.  By this I mean both CFGSimplify style elimination of constant branch conditions, but also CVP, KnownBits, and SCEV.  (Today, this is often true on entry to a loop pass manager, but is not upheld as passes run.) To be clear, the above list is aspirational.  We definitely don't do all of the above today.  :) Phil...

Hi, I think we should remove the LoopInstSimplify pass, as it has no test coverage and no users (afaik). If you are using the pass, or think that it should stay in tree for some other reason, please let me know. Here's the patch: https://reviews.llvm.org/D44053 <https://reviews.llvm.org/D44053> vedant -------------- next part -------------- An HTML attachment was scrubbed... URL:

...oop as well, but that's less >> clear to me. >> * All trivial LICM done.  By this I mean LICM which does not >> require aliasing or speculation safety logic.  This is >> Loop::makeInvariant. >> * All trivial branches discharged.  By this I mean both CFGSimplify >> style elimination of constant branch conditions, but also CVP, >> KnownBits, and SCEV.  (Today, this is often true on entry to a >> loop pass manager, but is not upheld as passes run.) >> >> To be clear, the above list is aspirational.  We definitely don...

...ding performance regression. What do you think? > > Thanks, > Wei. I tried the idea and it worked for the simple case, but didn't work when compiling MemorySSA.cpp. That is because for the following pattern: foo(c) { b = phi(c, undef) t = (a == b) loop: if (t) end loop } cfgsimplify will convert it to foo(c) { b = select i1 cond i32 c, undef t = (a == b) loop: if (t) end loop } And instcombine can remove the select and generate: foo(c) { t = (a == c) loop: if (t) end loop } Now c is a param so loop unswitch kicks in. However, the argument of foo is unde...

Hello, Recently I've come across two instances where Induction Variable Simplification lead to noticable performance regressions. In one case, the removal of extra IV lead to the inability to reschedule instructions in a tight loop to reduce stalls. In that case, there were enough registers to spare, so using extra register for extra induction variable was preferable since it reduced

...it worked for the simple case, but didn't work > when compiling MemorySSA.cpp. That is because for the following > pattern: > > foo(c) { > b = phi(c, undef) > t = (a == b) > loop: > if (t) > end loop > } > > cfgsimplify will convert it to > foo(c) { > b = select i1 cond i32 c, undef > t = (a == b) > loop: > if (t) > end loop > } > > And instcombine can remove the select and generate: > foo(c) { > t = (a == c) > loop: &g...

Hi, On Mon, Jul 17, 2017 at 1:56 PM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Mon, Jul 17, 2017 at 1:53 PM, Wei Mi <wmi at google.com> wrote: >> >> It seems MemorySSA.cpp is the only real code where we found the >> problem happening. > > > This is doubtful, ¸FWIW :) > >> >> Is it possible to change the

Hi Danny, Thanks for that :) However I've just updated the prototype patch to NewGVN and it didn't need any API changes - all I rely on is GVNExpression. Hongbin, I wanted to explain a little about what GVNSink can currently do, what it was designed for and hopefully how to make it handle your testcase. *Background* Common code sinking is more difficult to efficently do than one might