[LLVMdev] What does this error mean: psuedo instructions should be removed before code emission?

[Dale Johannesen]

On Aug 27, 2010, at 3:43 PMPDT, Yuri wrote:

> On 08/27/2010 12:13, Dale Johannesen wrote:
> Here's what happens:
> The first instruction created is RET.
> SelectBasicBlock is called.
> TCRETURNri64 is created from within it.
> HasTailCall is set to true as you mentioned.
> Cycle in SelectionDAGISel::SelectBasicBlock skips the rest.
>
> All like you described. But the RET instruction still stays in the  
> end.
> RET is skipped by visit but I guess stays in the list. Where should  
> it be destroyed?


Ahh, this is a bug in FastISel, which I didn't have turned on, that's  
why I wasn't seeing this.  Looks like the rewrite to go bottom-up,  
108039, introduced this.  The logic there doesn't work with tail  
calls.  Dan, could you look?
Minimal example:

; ModuleID = '<stdin>'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32- 
i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64- 
f80:128:128-n8:16:32:64"
target triple = "x86_64-apple-darwin11.0"

define i32 @foo() nounwind ssp {
entry:
   %0 = tail call i32 (...)* @bar() nounwind       ; <i32> [#uses=1]
   ret i32 %0
}

Output of llc -O0 :

	.section	__TEXT,__text,regular,pure_instructions
	.globl	_foo
	.align	4, 0x90
_foo:                                   ## @foo
## BB#0:                                ## %entry
	xorb	%al, %al
	#TC_RETURN _bar $0
	movl	-4(%rsp), %eax          ## 4-byte Reload
	ret

In this case it doesn't crash at compile time, but it's very wrong.