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?


Hello Félix-

Consider the following snippet of IR:

define i32 @foo(i32 %n) nounwind {
  br label %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
  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.


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 {
%time = call i32 @time(i32* null) nounwind
%cmp = icmp eq i32 %time, 1234567890
br i1 %cmp, label %exit, label %entry
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.


It’s inherent to the entry block. A lot of things are special about the entry block; allowing branches to it would make everything else more complicated.