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: