[LLVMdev] Help with error in pass
Chris Lattner
sabre at nondot.org
Sat Jun 24 13:29:06 PDT 2006
On Sat, 24 Jun 2006, Fernando Magno Quintao Pereira wrote:
> I've solved my problem with the passes, and compiled my first code
> using the new register allocator! Debugging was quite easy, using gdb.
> The problem was that I was forgetting to initialize the array that records
> the physical registers ever used (MachineFunction::UsedPhysRegs). This is
Great!
> a very minor thing, but I would suggest asserting that the vector has
> been initialized before it is used in functions such as
> runOnMachineFunction::X86FloatingPoint.cpp or
> PPCRegisterInfo::emitPrologue.
Sure, please send in a patch :)
> Now I have another question. My register allocator is generating code
> like this:
>
> .text
> .align 16
> .globl main
> main:
> subl $2, %esp
> fnstcw (%esp)
> movb $2, 1(%esp)
> fldcw (%esp)
> xorl %eax, %eax
> movl %eax, %eax <----------------------
> addl $2, %esp
> ret
> .size main, .-main
>
> Whereas RegAllocLocal.cpp is producing this one here:
> .text
> .align 16
> .globl main
> main:
> subl $2, %esp
> fnstcw (%esp)
> movb $2, 1(%esp)
> fldcw (%esp)
> xorl %eax, %eax
> addl $2, %esp
> ret
> .size main, .-main
>
> Is it the "Two-Address instruction pass" that is removing that move marked
> above?
The "spiller" does this. It is the code that, given a mapping of vregs to
physregs and vregs to stack slots, rewrites to code and optimizes spill
code. I'd highly recommend using it. The code is in
CodeGen/VirtRegMap.*.
-Chris
> Thanks a lot,
>
> Fernando
>
>
>> On Fri, 23 Jun 2006, Fernando Magno Quintao Pereira wrote:
>>> I am getting an error with my pass implementation, and I cannot figure
>>> it out. Basically, I've implemented part of a register allocation
>>> algorithm, but I am having problems to set the passes correctly. For
>>> instance, for this program below, the following error message is
>>> produced:
>>
>> It's hard to say without more details, i.e. a stack trace in gdb. What
>> pass is it crashing in, for example?
>>
>> -Chris
>>
>>> .c ----------------------| .bc ---------------------------------
>>> | Live Outs: EAX
>>> |
>>> #include <stdio.h> | entry (0x8d4c6c0, LLVM BB @0x8d46970):
>>> | FNSTCW16m <fi#0>, 1, %NOREG, 0
>>> int main() { | MOV8mi <fi#0>, 1, %NOREG, 1, 2
>>> return 0; | FLDCW16m <fi#0>, 1, %NOREG, 0
>>> } | %reg1024 = MOV32r0
>>> | %EAX = MOV32rr %reg1024
>>> | RET
>>>
>>> llc((anonymous namespace)::PrintStackTrace()+0x18)[0x88cfa30]
>>> llc((anonymous namespace)::SignalHandler(int)+0x107)[0x88cfcc1]
>>> /lib/tls/libc.so.6[0x239f48]
>>> llc(llvm::MachineFunctionPass::runOnFunction(llvm::Function&)+0x28)[0x8400638]
>>> llc(llvm::FunctionPassManagerT::runPass(llvm::FunctionPass*,
>>> llvm::Function*)+0x1b)[0x8857349]
>>> llc(llvm::PassManagerT<llvm::FTraits>::runPasses(llvm::Function*,
>>> std::map<llvm::Pass*, std::vector<llvm::Pass*, std::allocator<llvm::Pass*>
>>>> , std::less<llvm::Pass*>, std::allocator<std::pair<llvm::Pass* const,
>>> std::vector<llvm::Pass*, std::allocator<llvm::Pass*> > > >
>>>> &)+0x11c)[0x8858bca]
>>> llc(llvm::PassManagerT<llvm::FTraits>::runOnUnit(llvm::Function*)+0x16f)[0x885865f]
>>> llc(llvm::FunctionPassManagerT::runOnFunction(llvm::Function&)+0x22)[0x8858e84]
>>> llc(llvm::FunctionPass::runOnModule(llvm::Module&)+0xa6)[0x8854bd2]
>>> llc(llvm::ModulePassManager::runPass(llvm::ModulePass*,
>>> llvm::Module*)+0x1b)[0x8857541]
>>> llc(llvm::PassManagerT<llvm::MTraits>::runPasses(llvm::Module*,
>>> std::map<llvm::Pass*, std::vector<llvm::Pass*, std::allocator<llvm::Pass*>
>>>> , std::less<llvm::Pass*>, std::allocator<std::pair<llvm::Pass* const,
>>> std::vector<llvm::Pass*, std::allocator<llvm::Pass*> > > >
>>>> &)+0x11c)[0x88596cc]
>>> llc(llvm::PassManagerT<llvm::MTraits>::runOnUnit(llvm::Module*)+0x16f)[0x8859161]
>>> llc(llvm::ModulePassManager::runOnModule(llvm::Module&)+0x22)[0x8853bea]
>>> llc(llvm::PassManager::run(llvm::Module&)+0x1f)[0x8853f81]
>>> llc(main+0xee2)[0x83d36ea]
>>> /lib/tls/libc.so.6(__libc_start_main+0xe4)[0x227ad4]
>>> llc[0x83d2779]
>>> Segmentation fault (core dumped)
>>> ------------------------------------------------------------------------------
>>>
>>> My allocator is assigning EAX to %reg1024, and this is exactly what any of
>>> the LLVM built-in allocators do. The list of passes that I am invoking is
>>> as follows:
>>>
>>> Pass Arguments: -verify -loopsimplify -loop-reduce -lowergc -lowerinvoke
>>> -unreachableblockelim
>>> Target Data Layout
>>> Debug Information
>>> Module Pass Manager
>>> Function Pass Manager
>>> Immediate Dominators Construction
>>> ET Forest Construction
>>> Module Verifier
>>> -- Module Verifier
>>> Natural Loop Construction
>>> Dominator Set Construction
>>> Dominator Tree Construction
>>> -- Immediate Dominators Construction
>>> Canonicalize natural loops
>>> -- Dominator Set Construction
>>> -- Dominator Tree Construction
>>> Scalar Evolution Analysis
>>> Loop Strength Reduction
>>> -- ET Forest Construction
>>> -- Scalar Evolution Analysis
>>> -- Canonicalize natural loops
>>> -- Loop Strength Reduction
>>> -- Natural Loop Construction
>>> Lower GC intrinsics, for GCless code generators
>>> -- Lower GC intrinsics, for GCless code generators
>>> Lower invoke and unwind, for unwindless code generators
>>> -- Lower invoke and unwind, for unwindless code generators
>>> Remove unreachable blocks from the CFG
>>> -- Remove unreachable blocks from the CFG
>>> X86 DAG->DAG Instruction Selection
>>> -- X86 DAG->DAG Instruction Selection
>>> **************** Due to my register allocator *******************
>>> Immediate Dominators Construction
>>> ET Forest Construction
>>> -- Immediate Dominators Construction
>>> Natural Loop Construction
>>> -- ET Forest Construction
>>> Virtual to def/use mapping - Fernando.
>>> -- Natural Loop Construction
>>> Edge liveness analyses - Fernando.
>>> Register allocation via coloring of chordal graphs.
>>> -- Register allocation via coloring of chordal graphs.
>>> -- Virtual to def/use mapping - Fernando.
>>> -- Edge liveness analyses - Fernando.
>>> *****************************************************************
>>> Live Variable Analysis
>>> X86 FP Stackifier
>>> -- X86 FP Stackifier
>>> -- Live Variable Analysis
>>> Prolog/Epilog Insertion & Frame Finalization
>>> -- Prolog/Epilog Insertion & Frame Finalization
>>> X86 AT&T-Style Assembly Printer
>>> -- X86 AT&T-Style Assembly Printer
>>> Machine Code Deleter
>>> -- Machine Code Deleter
>>>
>>> Could some one tell me what is(are) the most likely reason(s) for this
>>> error? I would really appreciate any help,
>>>
>>> Thanks a lot,
>>>
>>> Fernando
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>> -Chris
>>
>> --
>> http://nondot.org/sabre/
>> http://llvm.org/
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-Chris
--
http://nondot.org/sabre/
http://llvm.org/
More information about the llvm-dev
mailing list