search for: subfuctions

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

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

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