llvm dev - May 2006 - [LLVMdev] ExecutionEngine blew the stack ?

Hi Simon,

You're probably right. LLVM's instruction selector is recursive so it  
can run out of stack space. Select_store used to have enormous stack  
frame (thanks to some gcc issues), we had to do all kinds of tricks  
to get it under control. I just took a look at it, it's around 0.7k.  
It used to be around 20k on x86 Mac OS X.

It's also possible that it has gotten into a real infinite loop. I'll  
take a look at it tomorrow.

Could you increase the stack limit on your system and see if that  
works around this problem?

Cheers,

Evan

On May 5, 2006, at 5:14 AM, Simon Burton wrote:
>
> Segfault in  EE->getPointerToFunction.
> I think it's blown the stack, gdb reports a never ending backtrace  
> (below).
>
> I generate llvm assembly and parse/verify OK.
> Attached is the assembly. It is the smallest example
> generated that causes the segfault.
>
> If this EE uses a recursive function (??), it seems an inherent  
> limitation
> in how big llvm functions can be.
>
> Simon.
>
> gdb backtrace:
> #0  0x40b126a3 in (anonymous  
> namespace)::X86DAGToDAGISel::Select_store(llvm::SDOperand&,  
> llvm::SDOperand) (this=0x822d660,
>     Result=@0xbf800a10, N={Val = 0x8254338, ResNo = 0}) at  
> X86GenDAGISel.inc:19768
> #1  0x40b01b44 in (anonymous namespace)::X86DAGToDAGISel::SelectCode 
> (llvm::SDOperand&, llvm::SDOperand) (this=0x822d660,
>     Result=@0xbf800a10, N={Val = 0x8254338, ResNo = 0}) at  
> X86GenDAGISel.inc:27833
> #2  0x40ada64f in (anonymous namespace)::X86DAGToDAGISel::Select 
> (llvm::SDOperand&, llvm::SDOperand) (this=0x822d660,
>     Result=@0xbf800a10, N={Val = 0x8254338, ResNo = 0}) at  
> X86ISelDAGToDAG.cpp:835
> #3  0x40b00bb4 in (anonymous namespace)::X86DAGToDAGISel::SelectCode 
> (llvm::SDOperand&, llvm::SDOperand) (this=0x822d660,
>     Result=@0xbf800d28, N={Val = 0x8254458, ResNo = 0}) at  
> X86GenDAGISel.inc:27686
> #4  0x40ada64f in (anonymous namespace)::X86DAGToDAGISel::Select 
> (llvm::SDOperand&, llvm::SDOperand) (this=0x822d660,
>     Result=@0xbf800d28, N={Val = 0x8254458, ResNo = 0}) at  
> X86ISelDAGToDAG.cpp:835
> #5  0x40b9886e in (anonymous  
> namespace)::X86DAGToDAGISel::Select_X86call(llvm::SDOperand&,  
> llvm::SDOperand) (
>     this=0x822d660, Result=@0xbf801098, N={Val = 0x82544d0, ResNo =  
> 0}) at X86GenDAGISel.inc:658
> #6  0x40b01391 in (anonymous namespace)::X86DAGToDAGISel::SelectCode 
> (llvm::SDOperand&, llvm::SDOperand) (this=0x822d660,
>     Result=@0xbf801098, N={Val = 0x82544d0, ResNo = 0}) at  
> X86GenDAGISel.inc:27760
> #7  0x40ada64f in (anonymous namespace)::X86DAGToDAGISel::Select 
> (llvm::SDOperand&, llvm::SDOperand) (this=0x822d660,
>     Result=@0xbf801098, N={Val = 0x82544d0, ResNo = 0}) at  
> X86ISelDAGToDAG.cpp:835
>
> etc....
>
> -- 
> Simon Burton, B.Sc.
> Licensed PO Box 8066
> ANU Canberra 2601
> Australia
> Ph. 61 02 6249 6940
> http://arrowtheory.com
> <dump.ll>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Fri, 5 May 2006, Simon Burton wrote:
> This leads me to my next question: as I make more and more functions
> with the EE, it slows down. I am re-using the Module,
ExistingModuleProvider,
> and ExecutionEngine, and pumping the parser like so:
>   M = ParseAssemblyString(AsmString, M);
> ISTM that there should be a way of creating multiple modules/EEs but I ran
> into trouble when I tried that (some time ago).
Can you quantify what you mean?  How does it "slow down"?

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/