llvm dev - Aug 2010 - [LLVMdev] What does this error mean: psuedo instructions should be removed before code emission?

On 08/27/2010 12:13, Dale Johannesen wrote:
> I don't think I believe this; emitPrologue should not be generating a 
> TCRETURN at all, and line 1037 is generating a PROLOG_LABEL.  Why do 
> you say it's a TCRETURN?
Sorry, my bad. I have set breakpoints by MI addresses. But it turns out 
that these addresses were reused and the second MIs created at these 
particular addressed are of interest, not the first ones.

RET creation stack (created first):
#1  0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr 
(this=0x30eb000, TID=@0x803a99240, DL={LineCol = 0, ScopeIdx = 0}, 
NoImp=false) at /tmp/llvm-svn/llvm/lib/CodeGen/MachineFunction.cpp:153
#2  0x00000008028ea45b in llvm::BuildMI (BB=@0x4b69378, 
I={<std::iterator<std::bidirectional_iterator_tag, llvm::MachineInstr, 
long int, llvm::MachineInstr*, llvm::MachineInstr&>> = {<No data 
fields>}, NodePtr = 0x4b69388}, DL={LineCol = 0, ScopeIdx = 0}, 
TID=@0x803a99240) at MachineInstrBuilder.h:183
#3  0x00000008033c7637 in X86SelectRet (this=0x4530f30, I=0x493f240) at 
/tmp/llvm-svn/llvm/lib/Target/X86/X86FastISel.cpp:771
#4  0x00000008033cc4fc in TargetSelectInstruction (this=0x4530f30, 
I=0x493f240) at /tmp/llvm-svn/llvm/lib/Target/X86/X86FastISel.cpp:1783
#5  0x000000080315a64f in llvm::FastISel::SelectInstruction 
(this=0x4530f30, I=0x493f240) at 
/tmp/llvm-svn/llvm/lib/CodeGen/SelectionDAG/FastISel.cpp:706
#6  0x0000000803275ee0 in llvm::SelectionDAGISel::SelectAllBasicBlocks 
(this=0x45174d0, Fn=@0x4530bd0) at 
/tmp/llvm-svn/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:726
#7  0x00000008032737f7 in llvm::SelectionDAGISel::runOnMachineFunction 
(this=0x45174d0, mf=@0x30eb000) at 
/tmp/llvm-svn/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:252V
#8  0x0000000802c92abd in llvm::MachineFunctionPass::runOnFunction 
(this=0x45174d0, F=@0x4530bd0) at 
/tmp/llvm-svn/llvm/lib/CodeGen/MachineFunctionPass.cpp:33
#9  0x0000000802e76e77 in llvm::FPPassManager::runOnFunction 
(this=0x235e540, F=@0x4530bd0) at 
/tmp/llvm-svn/llvm/lib/VMCore/PassManager.cpp:1443
#10 0x0000000802e76b3f in llvm::FunctionPassManagerImpl::run 
(this=0x1e1a300, F=@0x4530bd0) at 
/tmp/llvm-svn/llvm/lib/VMCore/PassManager.cpp:1394
#11 0x0000000802e767ef in llvm::FunctionPassManager::run 
(this=0x4b566c0, F=@0x4530bd0) at 
/tmp/llvm-svn/llvm/lib/VMCore/PassManager.cpp:1324
#12 0x0000000802f50500 in llvm::JIT::jitTheFunction (this=0x327a7e0, 
F=0x4530bd0, locked=@0x7fffffff8b50) at 
/tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:655
#13 0x0000000802f5037b in llvm::JIT::runJITOnFunctionUnlocked 
(this=0x327a7e0, F=0x4530bd0, locked=@0x7fffffff8b50) at 
/tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:633
#14 0x0000000802f507e4 in llvm::JIT::getPointerToFunction 
(this=0x327a7e0, F=0x4530bd0) at 
/tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:719
#15 0x0000000802f4f194 in llvm::JIT::runFunction (this=0x327a7e0, 
F=0x4530bd0, ArgValues=@0x7fffffff9230) at 
/tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:405
#16 0x0000000802f4fe4f in llvm::JIT::runFunction (this=0x327a7e0, 
F=0x4530c60, ArgValues=@0x7fffffff9350) at 
/tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:561

TCRETURNri64 creation stack (created second):
#1  0x0000000802c8b4e2 in llvm::MachineFunction::CreateMachineInstr 
(this=0x30eb000, TID=@0x803a9f840, DL={LineCol = 0, ScopeIdx = 0}, 
NoImp=false) at /tmp/llvm-svn/llvm/lib/CodeGen/MachineFunction.cpp:153
#2  0x00000008028ea302 in llvm::BuildMI (MF=@0x30eb000, DL={LineCol = 0, 
ScopeIdx = 0}, TID=@0x803a9f840) at MachineInstrBuilder.h:147
#3  0x0000000803164513 in llvm::InstrEmitter::EmitMachineNode 
(this=0x7fffffff7f80, Node=0x4b6c510, IsClone=false, IsCloned=false, 
VRBaseMap=@0x7fffffff8050) at 
/tmp/llvm-svn/llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:671
#4  0x00000008031f6bdf in llvm::InstrEmitter::EmitNode 
(this=0x7fffffff7f80, Node=0x4b6c510, IsClone=false, IsCloned=false, 
VRBaseMap=@0x7fffffff8050) at InstrEmitter.h:118
#5  0x00000008031f5781 in llvm::ScheduleDAGSDNodes::EmitSchedule 
(this=0x4b68400) at 
/tmp/llvm-svn/llvm/lib/CodeGen/SelectionDAG/ScheduleDAGSDNodes.cpp:602
#6  0x0000000803275459 in llvm::SelectionDAGISel::CodeGenAndEmitDAG 
(this=0x45174d0) at 
/tmp/llvm-svn/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:547
#7  0x00000008032740fc in llvm::SelectionDAGISel::SelectBasicBlock 
(this=0x45174d0, Begin={<std::iterator<std::bidirectional_iterator_tag, 
const llvm::Instruction, long int, const llvm::Instruction*, const 
llvm::Instruction&>> = {<No data fields>}, NodePtr = 0x4530ed0},
End={<std::iterator<std::bidirectional_iterator_tag, const 
llvm::Instruction, long int, const llvm::Instruction*, const 
llvm::Instruction&>> = {<No data fields>}, NodePtr = 0x493f240},
HadTailCall=@0x7fffffff853f) at 
/tmp/llvm-svn/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:364
#8  0x0000000803276048 in llvm::SelectionDAGISel::SelectAllBasicBlocks 
(this=0x45174d0, Fn=@0x4530bd0) at 
/tmp/llvm-svn/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:744
#9  0x00000008032737f7 in llvm::SelectionDAGISel::runOnMachineFunction 
(this=0x45174d0, mf=@0x30eb000) at 
/tmp/llvm-svn/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:252
#10 0x0000000802c92abd in llvm::MachineFunctionPass::runOnFunction 
(this=0x45174d0, F=@0x4530bd0) at 
/tmp/llvm-svn/llvm/lib/CodeGen/MachineFunctionPass.cpp:33
#11 0x0000000802e76e77 in llvm::FPPassManager::runOnFunction 
(this=0x235e540, F=@0x4530bd0) at 
/tmp/llvm-svn/llvm/lib/VMCore/PassManager.cpp:1443
#12 0x0000000802e76b3f in llvm::FunctionPassManagerImpl::run 
(this=0x1e1a300, F=@0x4530bd0) at 
/tmp/llvm-svn/llvm/lib/VMCore/PassManager.cpp:1394
#13 0x0000000802e767ef in llvm::FunctionPassManager::run 
(this=0x4b566c0, F=@0x4530bd0) at 
/tmp/llvm-svn/llvm/lib/VMCore/PassManager.cpp:1324
#14 0x0000000802f50500 in llvm::JIT::jitTheFunction (this=0x327a7e0, 
F=0x4530bd0, locked=@0x7fffffff8b50) at 
/tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:655
#15 0x0000000802f5037b in llvm::JIT::runJITOnFunctionUnlocked 
(this=0x327a7e0, F=0x4530bd0, locked=@0x7fffffff8b50) at 
/tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:633
#16 0x0000000802f507e4 in llvm::JIT::getPointerToFunction 
(this=0x327a7e0, F=0x4530bd0) at 
/tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:719
#17 0x0000000802f4f194 in llvm::JIT::runFunction (this=0x327a7e0, 
F=0x4530bd0, ArgValues=@0x7fffffff9230) at 
/tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:405
#18 0x0000000802f4fe4f in llvm::JIT::runFunction (this=0x327a7e0, 
F=0x4530c60, ArgValues=@0x7fffffff9350) at 
/tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:561

> The way this is supposed to work:
> SelectBasicBlock calls visit on the Call instruction, leading to 
> visitCall:
>  which winds up in X86TargetLowering::LowerCall:
> which generates the TCRETURN and sets the isTailCall argument to True
> which causes the loop in SelectBasicBlock to exit early, causing it to 
> skip the RET.
>
> It looks like the incoming RET (the Instruction, not the MachineInstr) 
> is not getting skipped for some reason.  I suggest stepping through 
> the path above to figure out why.
>
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?

Yuri

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.

I filed PR 8014 about this.

On Aug 27, 2010, at 4:16 PMPDT, Dale Johannesen wrote:
> 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?