search for: loopunswitch

Hi all. By now loops with switch instruction are unswitched value-by-value. For example for case range [0..9] we need to run unswitch process 10 times! I want try to optimize that case. Is there any hidden problems that blocks this improvement? Regards, Stepan.

Hi all. Guys in accordance to PR1255 I need to add case-ranges support for passes listed in subject. Who can review some of these passes in nearest future? Thanks! -Stepan.

...developers may also get hit by the same issue and the > > cost of leaving this issue open for long can be very high to the > community. > > I can't speak for others, but I am fine with adding a workaround for > this. However, I suspect isGuaranteedNotToBeUndefOrPoison in > LoopUnswitch may regress other benchmarks. > Any other thoughts on a more minimal fix? Otherwise, it sounds like we can only try to find the fix that does the least damage. We can't just leave it broken given it's triggering even in llvm bootstraps now :( -------------- next part -------------- An H...

...2f1008d4cbec8f22%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636357664258073352&sdata=iCy8kUlWwJzQpXbXvOuhHpKyXBnntZPGvn%2FtxWsqun8%3D&reserved=0. The short answer here is that the loop unswitch transform and the GVN transform are justified via conflicting specifications of undef (that is, LoopUnswitch and GVN don't agree on the definition of undef). The long(er) answer is in the bug. Unfortunately, there is no real way to fix this in the IR today (beyond hacking GVN / LoopUnswitch to back off on these transforms enough to not trigger this case). We will need to specify and implement a con...

...1af91ab2d7cd011 > db47%7C1%7C0%7C636357664258073352&sdata=iCy8kUlWwJzQpXbXvOuhHpKyXBnntZ > PGvn%2FtxWsqun8%3D&reserved=0. > > The short answer here is that the loop unswitch transform and the GVN > transform are justified via conflicting specifications of undef (that is, > LoopUnswitch and GVN don't agree on the definition of undef). The > > long(er) answer is in the bug. > > > > Unfortunately, there is no real way to fix this in the IR today (beyond > hacking GVN / LoopUnswitch to back off on these transforms enough to not > trigger this case). We w...

Hi all. Looking at test/Transforms/LoopUnswitch/preserve-analyses.ll, I found improper phi instruction at string #122: %call.i25.lcssa48 = phi i8* [ %call.i25, %if.then31.i.i ], [ %call.i25, %if.then31.i.i ] ; <i8*> [#uses=0] Is it trick or mistake? -Stepan.

...obey the typical "rules" of a pass over a narrow chunk of IR: they routinely access and modify IR outside of the loop. There appear to be two chunks of "functionality" provided by loop passes: 1) A worklist of loops to process. This is very rarely used: 1.1) LoopSimplify and LoopUnswitch add loops to the queue. 1.2) LoopExtractor, LoopDeletion, and LoopUnroll delete loops from the queue (but "no-op" would likely be correct if we didn't have the loop pass manager). 2) LoopUnswitch and the pass itself use some hooks to update analyses. This is only actually leveraged b...

...>> > cost of leaving this issue open for long can be very high to the > >> > community. > >> > >> I can't speak for others, but I am fine with adding a workaround for > >> this. However, I suspect isGuaranteedNotToBeUndefOrPoison in > >> LoopUnswitch may regress other benchmarks. > > > > Any other thoughts on a more minimal fix? > > I can't think of any good answers here. > > The semantic we want is "branching on poison or undef is undefined > behavior" (which lets us do propagateEquality). Given that,...

This is a bug found by internal compiler bootstrap, and possibly it is the root cause of https://bugs.llvm.org/show_bug.cgi?id=33652 and https://bugs.llvm.org/show_bug.cgi?id=33626. Here is the testcase 1.c. The original code is at MemorySSA.cpp:586 for rL307764. ------------------------- 1.c --------------------------- long a, c, d, e, f, m, cnt, i_hasval; volatile long b; void goo(long); void

...open for long can be very high to the >>> >> > community. >>> >> >>> >> I can't speak for others, but I am fine with adding a workaround for >>> >> this. However, I suspect isGuaranteedNotToBeUndefOrPoison in >>> >> LoopUnswitch may regress other benchmarks. >>> > >>> > Any other thoughts on a more minimal fix? >>> >>> I can't think of any good answers here. >>> >>> The semantic we want is "branching on poison or undef is undefined >>> behavior&q...

Hi, I have a general question on LoopUnswtich pass. Consider the following IR snippet: define i32 @test(i1 %cond) { br label %loop_begin loop_begin: br i1 %cond, label %loop_body, label %loop_exit loop_body: br label %do_something do_something: call void @some_func() noreturn nounwind br label %loop_begin loop_exit: ret i32 0 } declare void @some_func() noreturn After running

...es in the LICM pass, and it looks to me like colorEHFunclets() is probably being called a lot more often than it needs to be for functions that have Windows EH personality functions. For one thing, the funclet coloring is happening when computeLoopSafetyInfo() is called from LoopIdiomRecognize and LoopUnswitch but those passes don't use the coloring information. Beyond that, it's called for every loop within LICM even though in many case the information won't have changed since being computed for other loops in the same function. I was thinking about pulling the funclet coloring out of comp...

...ommunity. >> >>> >> >> >>> >> I can't speak for others, but I am fine with adding a workaround >> >>> >> for >> >>> >> this. However, I suspect isGuaranteedNotToBeUndefOrPoison in >> >>> >> LoopUnswitch may regress other benchmarks. >> >>> > >> >>> > Any other thoughts on a more minimal fix? >> >>> >> >>> I can't think of any good answers here. >> >>> >> >>> The semantic we want is "branching o...

...use the CloneLoop function > to clone a loop nest? I would like to point you to a code example, but then I realized nothing in the LLVM codebase actually uses CloneLoop. So I'm not surprised it's broken... sorry about that. For an actually working piece of code that clones a loop, try LoopUnswitch::UnswitchNontrivialCondition in lib/Transforms/Scalar/LoopUnswitch.cpp. -Eli

Stepan Dyatkovskiy wrote: > Hi all. > > Looking at test/Transforms/LoopUnswitch/preserve-analyses.ll, I found > improper phi instruction at string #122: > %call.i25.lcssa48 = phi i8* [ %call.i25, %if.then31.i.i ], [ %call.i25, > %if.then31.i.i ] ;<i8*> [#uses=0] > Is it trick or mistake? What's improper about it? The block may have two predecessors, b...

Hi, Which optimization passes use profile information? http://llvm.org/docs/Passes.html seems to suggest only block placement uses it, is that correct? Emma. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160715/46cc3ccc/attachment.html>

...increase caused by higher unrolling thresholds for non-cold code, we should factor that into the tradeoff in picking where the threshold goes. However, getting PGO into the full unroller is currently challenging outside of the new pass manager. We already have some unfortunate hacks around this in LoopUnswitch that are making the port of it to the new PM more annoying. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170131/44fac14b/attachment.html>

...>> >>>> >>> >> I can't speak for others, but I am fine with adding a workaround >>>> >>> >> for >>>> >>> >> this. However, I suspect isGuaranteedNotToBeUndefOrPoison in >>>> >>> >> LoopUnswitch may regress other benchmarks. >>>> >>> > >>>> >>> > Any other thoughts on a more minimal fix? >>>> >>> >>>> >>> I can't think of any good answers here. >>>> >>> >>>> >&g...

...a few key places and get a lot of benefit (there is a particular use case for prior to LICM, at least). FWIW, I don't think that adding an SCEV dependency before LICM would be particularly problematic: Currently, LICM lives in the same loop pass manager instance as LoopSimplify, LoopRotate and LoopUnswitch, all of which preserve SE. Suggestions? Thanks again, Hal -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory

OK. Thanks. And if I removed "case 4:" for example. Need I scan all phi nodes and fix it, by removing one predecessor (if it exists) to switch's parent block? -Stepan. Nick Lewycky wrote: > Stepan Dyatkovskiy wrote: >> Hi all. >> >> Looking at test/Transforms/LoopUnswitch/preserve-analyses.ll, I found >> improper phi instruction at string #122: >> %call.i25.lcssa48 = phi i8* [ %call.i25, %if.then31.i.i ], [ %call.i25, >> %if.then31.i.i ] ;<i8*> [#uses=0] >> Is it trick or mistake? > > What's improper about it? > > The bl...