[LLVMdev] ExecutionEngine blew the stack ?

Simon Burton simon at arrowtheory.com
Thu May 4 23:16:44 PDT 2006


On Thu, 4 May 2006 22:27:08 -0700
Evan Cheng <evan.cheng at apple.com> wrote:

> 
> 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

It works fine on smaller problem sizes, so I don't think it is a problem
with the EE's control flow.

I don't know how to increase the stack limit. And even if I did
I would just want to run it on bigger problems..

But it should be documented somewhere that this is a limitation.
And/or, some kind of runtime check that each basic block/function
is not too big (maybe that's too hard to check).

In my case the function is eminantly decomposable into subfuctions so it
looks like that's the correct way to handle this.

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).

Is there a way around this ? I'm looking for scalability.

Simon.

-- 
Simon Burton, B.Sc.
Licensed PO Box 8066
ANU Canberra 2601
Australia
Ph. 61 02 6249 6940
http://arrowtheory.com 




More information about the llvm-dev mailing list