search for: selectcode

Thanks Ahmed and also Alex for your replies. This is more or less what I was realising, but it is a great confidence booster to know that it is the correct way also. I can replace all of my various 'Select*' specialisations with version that use 'ReplaceNode/SelectCode' and return 'void', but what about the places where I currently call 'Select(N)' directly? Should I substitute 'SelectCode(N)' instead? I will examine the X86 implementation as you recommend and hope to glean some knowledge from that. All the best, MartinO -----Ori...

...t; Thanks Ahmed and also Alex for your replies. > > This is more or less what I was realising, but it is a great > confidence booster to know that it is the correct way also. I can > replace all of my various 'Select*' specialisations with version that > use 'ReplaceNode/SelectCode' and return 'void', but what about the > places where I currently call 'Select(N)' directly? Should I > substitute 'SelectCode(N)' instead? Maybe, but be aware that `N` won't necessarily be a valid reference anymore after calling SelectCode - it may have been...

It occurred to me that instead of the various breakout 'Select*' functions returning the 'SDNode*' result, maybe I should be calling: ReplaceNode(N, newValue); return; or: SelectCode(N); return; Perhaps? MartinO From: Martin J. O'Riordan [mailto:martin.oriordan at movidius.com] Sent: 28 June 2016 16:49 To: 'LLVM Developers' <llvm-dev at lists.llvm.org> Subject: Question about changes to 'SelectionDAGISel.h' Although I wo...

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. > > Removing the...

...iordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > It occurred to me that instead of the various breakout ‘Select*’ functions > returning the ‘SDNode*’ result, maybe I should be calling: > > > > ReplaceNode(N, newValue); > > return; > > or: > > SelectCode(N); > > return; > > > > Perhaps? Yes, I think the core difference is that Select() - not its caller - now does the replacement, so there's nothing to return. This is actually mentioned in the release notes (kudos to Justin!): SelectionDAGISel::Select now returns void....

...an 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 = 0x82...

...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 into smaller...

...9;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 improves the sit...

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

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 >> have nega...

...an 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 = 0x82...

...21: ch = store<ST64[%6](align=4)> t20, t19, t6, undef:i64 I don't understand why because it seems to me store is specified well in [MyTarget]InstrInfo.td . Can somebody help with an idea? Myself I will try to debug the code generated with TableGen, implementing the function SelectCode() . Best regards, Alex

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

...y, TableGen generates all the instruction selection functions (in the .inc file) as if they were top-most functions. To make them members of their corresponding SelectionDAGISel derivative, each target has to include the .inc file directly into the body of the class: --- FooDAGISel.inc --- void SelectCode(Node *N) { // 1E6 lines of pattern matching code } ... ---------------------- --- FooISelDAGToDAG.cpp --- class FooDAGToDAGISel : public SelectionDAGISel { #include "FooDAGISel.inc" }; --------------------------- If someone wanted to put the class definition in a separate header file...

...asmstr, list<dag> pattern> : Instruction { let Namespace = "AMD"; dag OutOperandList = outs; dag InOperandList = ins; let Pattern = pattern; let AsmString = asmstr; OpCodeModifier ocmod; } How do I set/read the ocmod struct from either SelectCode or a separate phase? Is there an example of this? Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054 P: 408-572-6219 F: 408-572-6596 -------------- next part -------------- An HTML attachmen...

...ad = load <16 x i32>, <16 x i32>* %21, align 4 br i1 %48, label %middle.block.unr-lcssa, label %vector.body, !llvm.loop !3 How do you suggest to attack this problem? I guess I need to provide custom matching code in the Select() function of the back end prior to the SelectCode() invocation in order to translate the label vector.body in LLVM/Machine Instr(DAG) before selection to a REPEAT_X_TIMES(...) instruction - are you aware if anybody else has done such a thing? Also, the br LLVM instruction will be translated to an END_REPEAT. Thank you, Alex

On 1/15/2016 2:57 PM, Phil Tomson wrote: > > > I see the following in my SelectCode (in XSTGGenDGISel.inc): > > > /*2235*/ OPC_SwitchOpcode /*2 cases */, 27, > TARGET_VAL(XSTGISD::ADDR_NORMAL),// ->2266 > /*2239*/ OPC_RecordChild0, // #1 = $addr > /*2240*/ OPC_MoveChild, 0, > /*2242*/ OPC_CheckOpcode, TARGET_VAL(ISD::Target...

On 1/15/2016 1:08 PM, Phil Tomson wrote: > > Ah, I see, the defm is a multi-class so I needed to change it to: > > def: Pat<(load (XSTGADDR_NORMAL tglobaladdr:$addr)), > (LOADI64_RI tglobaladdr:$addr, 0)>; > // Match load from a relocatable address to a load with GRP: > def: Pat<(load (XSTGADDR_USE_GRP tglobaladdr:$addr)), > (LOADI64_RI

...interactions between ARCHInstrInfo.td and ARCHDAGToDAGISel.cpp I did manage to hack something together based on a copy of SPARC (with a SABRE namespace etc) but the instruction selection was incorrect and I obtained a "Cannot yet select:0x..." assertion failure from SABREDAGToDAGIsel::SelectCode when I attempted a llc -march sabre helloworld.bc -o helloworld.s Can anyone offer any guidance on how to proceed with debugging instruction selection issues? Or perhaps some description of how the pattern matching and the instruction selection works with a verbose explanation for a single ins...

...quot;sdiv", 0b001111>; Is this because these instructions are handled differently from other instructions in SparcISelDAGToDAG.cpp? In function SparcDAGToDAGISel::Select(SDValue Op), instruction selection for "sdiv" and "udiv" is done in the switch-case statement, while SelectCode(Op) takes care of the other instructions*. * Thank you.. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100101/e762fa15/attachment.html>