search for: x86dagtodagisel

...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=@0xbf800...

...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=@0xbf800...

...mbly. 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=0...

...LiveInterval. It does keep a lot > of information but it's all essential. > > I suspect StrongPHIElimination may help the situation somewhat but > again I can't guess its impact. > > 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? >> I don't see any easy solution to reduce memory usage, but should we >> optimize such a huge function at once? >> If the function is over some reasonable limit (5k basic-blocks?) we >> could split it i...

...ir/devel/llvm/llvm.src/lib/CodeGen/SelectionDAG/ ScheduleDAG.cpp:834 #11 0x007f820e in llvm::SelectionDAGISel::ScheduleAndEmitDAG (this=0x42025600, DAG=@0xbfffe47c) at /Volumes/Gir/devel/llvm/ llvm.src/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:4847 #12 0x0067fcca in (anonymous namespace)::X86DAGToDAGISel::InstructionSelectBasicBlock (this=0x42025600, DAG=@0xbfffe47c) at /Volumes/Gir/devel/llvm/ llvm.src/lib/Target/X86/X86ISelDAGToDAG.cpp:483 #13 0x007f80cc in llvm::SelectionDAGISel::CodeGenAndEmitDAG (this=0x42025600, DAG=@0xbfffe47c) at /Volumes/Gir/devel/llvm/ llvm.src/lib/CodeGen/Selection...

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 penalty is only 2000, thus we still > have negative costs. > > R...

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]

I am trying to understand the SelectionDAG construction from LLVM IR. I have gone through the doc "The LLVM Target-Independent Code Generator" on LLVM site. This gives a great initial overview. However I am unable to catch the actual control flow for the llvm->selectionDag conversion. The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( "llc

Hi Bruce, Thanks for you reply. I check the *.td files under the lib/Target/X86 folder, but have not got interesting findings. It requires some knowledge of LLVM backend to fully understand the *.td files. I will get some background and keep searching. Of course I appreciate if anyone with such experience can point the concrete locations. Regards, Hu Hong On 17 October 2016 at 22:20, Bruce

...failed on MultiSource/Applications/Burg test. I run bugpoint and it gives me bugpoint-reduced-simplified.bc. I run llc on this file with all LLVM register allocators and it gives the same result (under gdb): 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. Thanks. -- Three things are certain: Death, taxes, and lost data. Guess which has occ...

...rmation but it's all essential. >> >> I suspect StrongPHIElimination may help the situation somewhat but >> again I can't guess its impact. >> >> >> > > 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 penalty is only 2000, thus we still have negative costs. Removing the /20 factor from here impr...

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? >>>> >>> most of functions called by SelectCode get a -30000 cost reduction >>> because they are internal. >>> Even if Caller.size() is 40000, the penalty is only 2000...

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 >> because they are internal. >> Even if Caller.size() is 40000, the penalty is only 2000, thus we >> still >&g...

...documentation for code generation (http://www.llvm.org/docs/CodeGenerator.html) and am unsure if I understand it correctly, because I have trouble figuring out what actually to do in the code to accomplish my aim. There are the tablegen generated functions and custom C++ code (I guess that will be X86DAGToDAGISel::Select(SDValue)) that deal with selection. The runtime checks I want to add concern indirect jumps. So for example for all calls that jump to register values like call eax I want to insert a check ... (some test) ...# perform test jne error_label # jump if test fails call eax...

...d 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 DAGCombine to > X86DAGToDAGISel > https://reviews.llvm.org/D62327 > > [DAGCombine][X86][AArch64][AMDGPU][MIPS][PPC] (sub x, c) -> (add x, > -c) vector edition. > https://reviews.llvm.org/D62341 > > While they got stuck since i wasn't really interested in them > (i'm mostly interested in scalars,...

...completely separate passes over the dag? Why do "manual isel" and > "table driven isel" as separate passes? If they are interlaced, then > how is this different than what we already have? No, not as separate passes. Right now we have code like this in X86ISelDAGToDAG: X86DAGToDAGISel::Select(SDNode *Node) { ... switch (Opcode) { ...do a bunch of manual selection... } // If we get here we didn't select manually. SelectCode(); // Select via table-driven isel, abort if no match. } What I'm proposing is that we do this: X86DAGToDAGISel::Select(SDNode *Node)...

Currently it appears X86WrapperRIP is only implemented in the small code model, which causes code to fail to select in other code models. My particular use case is MCJIT, where the default code model is large (the X86WrapperRIP comes from a TLS variable reference). What would be the best way to implement this? I'd be happy to take a crack at it myself, but I really don't know my way around

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

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

...of the selection >> process. You can can even put a breakpoint on the Select >> function and view the graph as each individual instruction is >> selected. > > That might be more helpful. Thanks for the tip! > > Which Select function are you referring to? For example, X86DAGToDAGISel::Select, for the x86 target. > > >> It can get hairy with really large graphs, but if you're trying >> to understand instruction selection, it's often possible to reduce >> the testcases to a readable scale while still including the >> interesting parts. Selec...