Félix Cloutier
2010-Jul-08 06:16 UTC
[LLVMdev] Why shouldn't function entry blocks have predecessors?
The title says it all. verifyFunction checks it (Verifier.cpp, line 728). Why can't BasicBlocks that serve as a function's entry point also have predecessors? What keeps a function from looping back to its beginning? Félix -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100708/f365b611/attachment.html>
Alistair Lynn
2010-Jul-08 06:27 UTC
[LLVMdev] Why shouldn't function entry blocks have predecessors?
Hello Félix- Consider the following snippet of IR: define i32 @foo(i32 %n) nounwind { entry: br label %loop loop: %loop.n = phi i32 [0, %entry], [%tmp, %loop] call void @bar() nounwind %tmp = sub nsw i32 %loop.n, 1 %cmp = icmp eq i32 %tmp, 0 br i1 %cmp, label %exit, label %loop exit: ret i32 0 } declare void @bar() nounwind Try to merge the blocks "entry" and "loop" and all becomes clear when you hit the phi node. Alistair On 8 Jul 2010, at 07:16, Félix Cloutier wrote:> The title says it all. verifyFunction checks it (Verifier.cpp, line 728). > > Why can't BasicBlocks that serve as a function's entry point also have predecessors? What keeps a function from looping back to its beginning? > > Félix > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Félix Cloutier
2010-Jul-08 07:25 UTC
[LLVMdev] Why shouldn't function entry blocks have predecessors?
It's past 3 AM here, so maybe I really shouldn't be answering in this state of awakeness. However, what I understand from your example is that loops with counters must be entered from another block in order to use the phi instruction correctly, not that it should be invalid to branch to the entry block. It seems to me that it makes sense to go back to the entry point if looping is not directed by a counter. Consider the following snippet of invalid IR: define i32 @foo() nounwind { entry: %time = call i32 @time(i32* null) nounwind %cmp = icmp eq i32 %time, 1234567890 br i1 %cmp, label %exit, label %entry exit: ret i32 0 } declare i32 @time(i32*) nounwind Is the problem really inherent to the entry block, or is it rather inherent to the use of the phi instruction from the entry block? Thanks for your time. Félix Le 2010-07-08 à 02:27:03, Alistair Lynn a écrit :> Hello Félix- > > Consider the following snippet of IR: > > define i32 @foo(i32 %n) nounwind { > entry: > br label %loop > loop: > %loop.n = phi i32 [0, %entry], [%tmp, %loop] > call void @bar() nounwind > %tmp = sub nsw i32 %loop.n, 1 > %cmp = icmp eq i32 %tmp, 0 > br i1 %cmp, label %exit, label %loop > exit: > ret i32 0 > } > > declare void @bar() nounwind > > Try to merge the blocks "entry" and "loop" and all becomes clear when you hit the phi node. > > Alistair > > On 8 Jul 2010, at 07:16, Félix Cloutier wrote: > >> The title says it all. verifyFunction checks it (Verifier.cpp, line 728). >> >> Why can't BasicBlocks that serve as a function's entry point also have predecessors? What keeps a function from looping back to its beginning? >> >> Félix >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100708/43bab2f5/attachment.html>
Possibly Parallel Threads
- [LLVMdev] Why shouldn't function entry blocks have predecessors?
- [LLVMdev] Why shouldn't function entry blocks have predecessors?
- [LLVMdev] Processing functions in call graph SCC "order" with function-level analyses
- [LLVMdev] Can I use Clang to parse snippets of C++ code?
- [LLVMdev] Debug just-in-time compiled code on Mac OS