[LLVMdev] Why shouldn't function entry blocks have predecessors?

[Félix Cloutier]

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>