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 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, > > EvanIt 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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.ll
Type: application/octet-stream
Size: 68038 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20060505/faf9bba6/attachment.obj>