llvm dev - Jul 2010 - [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>

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

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>