search for: opc_checkopcode

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

...t; 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::TargetGlobalAddress), > /*2245*/ OPC_MoveParent, > /*2246*/ OPC_MoveParent, > /*2247*/ OPC_CheckPredicate, 5, // Predicate_unindexedload > /*2249*/ OPC_CheckPredicate, 6, // Predicate_load > /*2251*/ OPC_CheckType, MVT::i6...

Hi Daniel, Thanks for replying; I was hoping to get in touch with you on this issue. I had a look at how SelectionIDAG does it when generating the matcher table, and it does consider the implicit defs as additional output. Here is the match table generated for the pattern: /* 0*/ OPC_CheckOpcode, TARGET_VAL(ISD::SIGN_EXTEND), /* 3*/ OPC_MoveChild0, /* 4*/ OPC_CheckOpcode, TARGET_VAL(ISD::SHL), /* 7*/ OPC_MoveChild0, /* 8*/ OPC_CheckOpcode, TARGET_VAL(ISD::ANY_EXTEND), /* 11*/ OPC_RecordChild0, // #0 = $src /* 12*/ OPC_CheckChild0Type, MVT::i16, /* 14*/ OPC_M...

...this a chain of rules? > > Yes, your add becomes a MVrr instruction. This is likely the problem. > Do you know how to debug this, or do you want me to give you basic directions? I had a look at the matcher table and it looks as follows: /*4309*/ /*Scope*/ 12, /*->4322*/ /*4310*/ OPC_CheckOpcode, TARGET_VAL(MBPISD::RET_FLAG), /*4313*/ OPC_RecordNode, // #0 = 'retflag' chained node /*4314*/ OPC_CaptureGlueInput, /*4315*/ OPC_EmitMergeInputChains1_0, /*4316*/ OPC_MorphNodeTo, TARGET_VAL(MyTarget::RETL), 0|OPFL_Chain|OPFL_GlueInput|OPFL_Variadic0, 0/*#VTs...

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

...rs 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 > /*38*/ OPC_MoveChild, 1, > /*40*/ OPC_CheckOpcode, TARGET_VAL(ISD::Constant), > /*43*/ OPC_Scope, 65...

...erand. Both patterns have the same complexity and they are located at different scopes. For these two patterns, tblgen is producing the following isel opcodes: /*3244*/ /*Scope*/ 20, /*->3265*/ /*3245*/ OPC_RecordChild1, // #1 = $b /*3246*/ OPC_MoveChild, 1, /*3248*/ OPC_CheckOpcode, TARGET_VAL(ISD::Constant), /*3251*/ OPC_MoveParent, /*3252*/ OPC_CheckType, MVT::i16, /*3254*/ OPC_EmitConvertToTarget, 1, /*3256*/ OPC_MorphNodeTo, TARGET_VAL(ME::AADDMri), 0, and in the same logic chain of pattern checking, DADDri comes right after AADDMri (with Sco...

...ve the same complexity and they are located at different scopes. For these two patterns, tblgen is producing the following isel opcodes: > > /*3244*/ /*Scope*/ 20, /*->3265*/ > /*3245*/ OPC_RecordChild1, // #1 = $b > /*3246*/ OPC_MoveChild, 1, > /*3248*/ OPC_CheckOpcode, TARGET_VAL(ISD::Constant), > /*3251*/ OPC_MoveParent, > /*3252*/ OPC_CheckType, MVT::i16, > /*3254*/ OPC_EmitConvertToTarget, 1, > /*3256*/ OPC_MorphNodeTo, TARGET_VAL(ME::AADDMri), 0, > > and in the same logic chain of pattern checking, DADDri comes...

Hi Quentin, >> Yes, the dags in view-isel-dags and view-legalize-types-dags are correct (the add operations are here and are their results are used) and the dags are the same. > > And what about view-sched-dags? The DAG looks like I described below (*) > This one should give you what has been selected. So if this is not correct, you have indeed a problem in the selection

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 there, I try to JIT compile some bitcode and seeing the following error: LLVM ERROR: Cannot select: 0x28ec830: ch,glue = X86ISD::CALL 0x28ec7c0, 0x28ef900, Register:i32 %EDI, Register:i8 %AL, RegisterMask:Untyped, 0x28ec7c0:1 0x28ef900: i32 = X86ISD::Wrapper TargetGlobalAddress:i32<void (i8*, ...)* @_ZN5FooBr7xprintfEPKcz> 0 0x28ec520: i32 = TargetGlobalAddress<void (i8*, ...)*

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.

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