search for: opc_scop

Hi, I'd like to understand the order in which patterns are searched during ISEL. In the example below, indices are searched in ascending order from 808 to 3305, then it goes back to 3259 and eventually it matches the wrong instruction. Why did go back from 3305 to 3259? In my XXXGenDAGISel.inc, I can see that the correct instruction is at index 3420 but it never got there. ISEL: Starting

In an attempt to add vector registers to my target, I ran into a problem. LLVM started to complain about not being able to infer types from the provided DAG patterns for several classes of instructions. After a discussion on the llvm-dev mailing list and IRC channel the recommendation was to make DAG patterns for these classes of instructions more specific. Which is what was done. However after

...tor of LLVM is an interpreter that interpret the MatcherTable which consists of bytecodes generated by TableGen. I'm surprised to find that the structure of MatcherTable and the interpreter seems to be suitable for parallelization. So we propose a prototype that parallelizes the interpreting of OPC_Scope children that are possibly time-consuming. Here is some quick overview: We add two new opcodes: OPC_Fork and OPC_Merge. During DAG optimization process(utils/TableGen/DAGISelMatcherOpt.cpp). OPC_Fork would be added to the front of scope(OPC_Scope) children which fulfill following conditions: 1....

...tor of LLVM is an interpreter that interpret the MatcherTable which consists of bytecodes generated by TableGen. I'm surprised to find that the structure of MatcherTable and the interpreter seems to be suitable for parallelization. So we propose a prototype that parallelizes the interpreting of OPC_Scope children that are possibly time-consuming. Here is some quick overview: >> >> We add two new opcodes: OPC_Fork and OPC_Merge. During DAG optimization process(utils/TableGen/DAGISelMatcherOpt.cpp). OPC_Fork would be added to the front of scope(OPC_Scope) children which fulfill followin...

...tor of LLVM is an interpreter that interpret the MatcherTable which consists of bytecodes generated by TableGen. I'm surprised to find that the structure of MatcherTable and the interpreter seems to be suitable for parallelization. So we propose a prototype that parallelizes the interpreting of OPC_Scope children that are possibly time-consuming. Here is some quick overview: >> >> We add two new opcodes: OPC_Fork and OPC_Merge. During DAG optimization process(utils/TableGen/DAGISelMatcherOpt.cpp). OPC_Fork would be added to the front of scope(OPC_Scope) children which fulfill followin...

...the syntax. > > > Tablegen creates a xxxGenDAGISel.inc file in your target's build > directory. The "index" numbers that the debugging info shows correspond to > the numbers in that file. Here's an example from HexagonGenDAGISel.inc: > > /*28*/ OPC_Scope, 88|128,3/*472*/, /*->503*/ // 3 children in > Scope > /*31*/ OPC_MoveChild, 1, > /*33*/ OPC_CheckOpcode, TARGET_VAL(ISD::ADD), > /*36*/ OPC_RecordChild0, // #2 = $base > /*37*/ OPC_RecordChild1, // #3 = $offset > /*3...

Hello. I come back to this older thread. Again, because of i64immSExt32 I receive TableGen error "Could not infer all types in, pattern!" (exact details written below). So far I'm not able to generate selection code with TableGen for the ADD_r* instructions, etc: def i64immSExt32 : PatLeaf<(imm), [{return

...onvertToTarget, 1, /*3256*/ OPC_MorphNodeTo, TARGET_VAL(ME::AADDMri), 0, and in the same logic chain of pattern checking, DADDri comes right after AADDMri (with Scope changes in the middle) /*3285*/ OPC_RecordChild0, // #0 = $a /*3286*/ OPC_RecordChild1, // #1 = $b /*3287*/ OPC_Scope, 42, /*->3331*/ // 2 children in Scope /*3289*/ OPC_MoveChild, 1, /*3291*/ OPC_CheckOpcode, TARGET_VAL(ISD::Constant), /*3294*/ OPC_MoveParent, /*3295*/ OPC_CheckType, MVT::i16, /*3297*/ OPC_EmitNode, TARGET_VAL(ME::sextr), 0, 1/*#VTs*/, M...

...OPC_MorphNodeTo, TARGET_VAL(ME::AADDMri), 0, > > and in the same logic chain of pattern checking, DADDri comes right after AADDMri (with Scope changes in the middle) > > /*3285*/ OPC_RecordChild0, // #0 = $a > /*3286*/ OPC_RecordChild1, // #1 = $b > /*3287*/ OPC_Scope, 42, /*->3331*/ // 2 children in Scope > /*3289*/ OPC_MoveChild, 1, > /*3291*/ OPC_CheckOpcode, TARGET_VAL(ISD::Constant), > /*3294*/ OPC_MoveParent, > /*3295*/ OPC_CheckType, MVT::i16, > /*3297*/ OPC_EmitNode, TARGET_VAL(ME::sextr), 0, >...

Thanks Anton and Krzysztof! Here is the dump using the -debug flag. At this point I am not making much sense of this, would it be too much to ask if one of you could walk me through one of these lines? One thing that I didn't point out is that I never defined any separate floating point registers, not sure if this will pose any issue? Thanks again for your time! Jeff jeff at

On Mar 7, 2012, at 6:23 AM, Ivan Llopard <ivanllopard at gmail.com> wrote: > Hi Jim, > > Thanks for your response. > > Le 06/03/2012 22:54, Jim Grosbach a écrit : >> Hi Ivan, >> On Mar 3, 2012, at 4:48 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: >> >>> Hi, >>> >>> I'm facing a problem in llvm while porting it

Hi Jim, Thanks for your response. Le 06/03/2012 22:54, Jim Grosbach a écrit : > Hi Ivan, > On Mar 3, 2012, at 4:48 AM, Ivan Llopard<ivanllopard at gmail.com> wrote: > >> Hi, >> >> I'm facing a problem in llvm while porting it to a new target and I'll >> need some support. >> We have 2 kind of register, one for general purposes (i.e.