similar to: [LLVMdev] ExecutionEngine blew the stack ?

Displaying 20 results from an estimated 500 matches similar to: "[LLVMdev] ExecutionEngine blew the stack ?"

2006 May 05
1
[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
2006 May 05
0
[LLVMdev] ExecutionEngine blew the stack ?
(resending with smaller attachement) 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
2006 Sep 19
0
[LLVMdev] Testing a register allocator
> > If the test output claims that llc-beta fails, then your register > allocator is producing incorrect code. In a multisource directory, if you > use 'make bugpoint-llc-beta' in some failing test directory, bugpoint will > automatically reduce the failure to a smaller example for you. Ok. My allocator failed on MultiSource/Applications/Burg test. I run bugpoint and it
2007 Sep 05
1
[LLVMdev] Exception Problems
Hi Anton & Duncan, When I try to compile on Darwin now, I get this: $ /Volumes/Gir/devel/llvm/llvm-gcc-4.0.obj/gcc/xgcc <options> -o eh_alloc.o Assertion failed: (false && "Couldn't find the register class"), function getPhysicalRegisterRegClass, file /Volumes/Gir/devel/llvm/ llvm.src/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp, line 269.
2006 Sep 03
7
[LLVMdev] Testing a register allocator
On Sun, 3 Sep 2006, Tanya M. Lattner wrote: >> BTW, how can I run all tests only on LLC to reduce the amount of time to >> wait until tests are finished, if it's possible? > > In my previous reply to your question, I suggested you look at > TEST.llc.Makefile and TEST.llc.report in the test directory. Modifying > those makefile/report files to use your register allocator
2011 Mar 17
2
[LLVMdev] Long-Term ISel Design
Chris Lattner <clattner at apple.com> writes: >> 1. We have special target-specific operators for certain shuffles in X86, >> such as X86unpckl. > It also eliminates a lot of fragility. Before doing this, X86 > legalize would have to be very careful to specifically form shuffles > that it knew isel would turn into (e.g.) unpck operations. Now > instead of
2011 Mar 16
3
[LLVMdev] Long-Term ISel Design
All, As I've done more integrating of AVX work upstream and more tuning here, I've run across several things which are clunky in the current isel design. A couple examples I can remember offhand: 1. We have special target-specific operators for certain shuffles in X86, such as X86unpckl. I don't completely understand why but Bruno indicated it was to address inefficiecies.
2011 Mar 17
0
[LLVMdev] Long-Term ISel Design
On Mar 16, 2011, at 1:44 PM, David Greene wrote: > All, > > As I've done more integrating of AVX work upstream and more tuning here, > I've run across several things which are clunky in the current isel > design. A couple examples I can remember offhand: > > 1. We have special target-specific operators for certain shuffles in X86, > such as X86unpckl. I
2008 Apr 14
3
[LLVMdev] LiveVariables/LiveInterval on huge functions
Evan Cheng wrote: > On Apr 13, 2008, at 1:28 PM, Török Edwin wrote: > > >> Hi, >> >> In PR2193 LiveVariables runs out of memory on a 512M limit, after >> processing 11557 basicblocks. >> VirtRegInfo has ~180000 entries with ~700 bytes each. >> If I give it more memory (1.5G) it runs out of memory in LiveInterval. >> > > Some of the
2008 Apr 14
3
[LLVMdev] LiveVariables/LiveInterval on huge functions
On Mon, 14 Apr 2008, [ISO-8859-1] Török Edwin wrote: >> Another question to ask, is why that function became so large in the >> first place [X86DAGToDAGISel::SelectCode(llvm::SDOperand)] >> We have inline limits, don't we? > > most of functions called by SelectCode get a -30000 cost reduction > because they are internal. > Even if Caller.size() is 40000, the
2008 Apr 14
0
[LLVMdev] LiveVariables/LiveInterval on huge functions
Török Edwin wrote: > Evan Cheng wrote: > >> On Apr 13, 2008, at 1:28 PM, Török Edwin wrote: >> >> >> >>> Hi, >>> >>> In PR2193 LiveVariables runs out of memory on a 512M limit, after >>> processing 11557 basicblocks. >>> VirtRegInfo has ~180000 entries with ~700 bytes each. >>> If I give it more memory
2008 Apr 15
1
[LLVMdev] LiveVariables/LiveInterval on huge functions
Evan Cheng wrote: > On Apr 14, 2008, at 10:43 AM, Chris Lattner wrote: > > >> On Mon, 14 Apr 2008, [ISO-8859-1] Török Edwin wrote: >> >>>> Another question to ask, is why that function became so large in the >>>> first place [X86DAGToDAGISel::SelectCode(llvm::SDOperand)] >>>> We have inline limits, don't we? >>>>
2008 Apr 14
0
[LLVMdev] LiveVariables/LiveInterval on huge functions
On Apr 14, 2008, at 10:43 AM, Chris Lattner wrote: > On Mon, 14 Apr 2008, [ISO-8859-1] Török Edwin wrote: >>> Another question to ask, is why that function became so large in the >>> first place [X86DAGToDAGISel::SelectCode(llvm::SDOperand)] >>> We have inline limits, don't we? >> >> most of functions called by SelectCode get a -30000 cost reduction
2009 Jul 08
2
[LLVMdev] Selection of multiple instructions
Hi, I'm currently trying to modify LLVM to include runtime checks into X86 binaries. I've looked into some of the possibilities during the phases happening in LLVM and have the impression that inserting runtime checks during selection would be great, since lots of optimizations are already done and I can work directly with X86 instructions. I've read through the documentation for
2006 May 05
0
[LLVMdev] ExecutionEngine blew the stack ?
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
2019 Aug 26
2
LLVM X86 backend combineIncDecVector's transform
No objections from me to make it run later. I didn't see the potential conflicts when I added that code. Delayed combine, custom lowering, or DAGToDAGISel all seem like viable options to me. On Mon, Aug 26, 2019 at 2:04 PM Roman Lebedev <lebedev.ri at gmail.com> wrote: > I have previously posted these two patches: > > [X86][CodeGen][NFC] Delay `combineIncDecVector()` from
2009 Dec 03
2
[LLVMdev] Duplicate Label in Generates ISel
I've got the following problem in the X86 selector generated by TableGen: llvm/lib/Target/X86/X86GenDAGISel.inc:91821: error: duplicate case value llvm/lib/Target/X86/X86GenDAGISel.inc:91442: error: previously used here This seems to happen because of a pattern I added for VEXTRACTF128 which uses extract_subreg: [(set DSTREGCLASS:$dst, (DSTTYPE (extract_subreg
2006 Sep 19
5
[LLVMdev] Testing a register allocator
On Tue, 19 Sep 2006, Anton Vayvod wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x00634572 in (anonymous namespace)::X86DAGToDAGISel::DeleteNode ( > this=0x4c3b710, N=0x4c3e5c0) > at /llvm/obj/lib/Target/X86/X86GenDAGISel.inc:77 > 77 SDNode *Operand = I->Val; > > SEGFAULT seems to come before register allocation pass is being run. Are you
2011 Mar 18
0
[LLVMdev] Long-Term ISel Design
On Mar 17, 2011, at 9:32 AM, David A. Greene wrote: > Chris Lattner <clattner at apple.com> writes: >>> 1. We have special target-specific operators for certain shuffles in X86, >>> such as X86unpckl. > >> It also eliminates a lot of fragility. Before doing this, X86 >> legalize would have to be very careful to specifically form shuffles >> that
2010 Mar 02
1
[LLVMdev] Build Errors on Snow Leopard (tblgen assertion)
On the trunk version of LLVM I am getting the following build error on Snow Leopard (v10.6.2): llvm[3]: Building X86.td DAG instruction selector implementation with tblgen Assertion failed: (LHS->ID != RHS->ID), function operator(), file /Users/peckw/Projects/llvm/llvm-pristine/utils/TableGen/DAGISelEmitter.cpp, line 183. ... <cut - see full_stack_trace.txt> 0. Program arguments: