search for: opfl_chain

...;,mayStore=1, hasSideEffects=0,neverHasSideEffects=1 in def ADDErm: myInstr <0x0, (outs Intregs:$dst) (ins Intregs:$op0,MEMi:$op1), "", [set IntRegs:$dest (adde IntRegs:$op0, (load ADDRi:$op1))] > very unlucky, this instruction failed. in the generated match table, there was flag OPFL_Chain. it caused a token factor node to be created in switch case OPC_EmitMergeInputChains in SelectCodeCommon. very bad, all uses of input chain was replaced with ADDErm Node. so the created token factor node depends on the ADDErm node after the replacement. very bad the ADDCrm node depends on...

...second load in the COMBINE_rr) is changed to LDriw_indexed similar to the first load. I see the following in HexagonGenDAGISel.inc *********************************************** /*1161*/ OPC_EmitConvertToTarget, 2, /*1163*/ OPC_EmitNode, TARGET_VAL(Hexagon::LDriw_indexed), 0|OPFL_Chain, 1/*#VTs*/, MVT::i32, 2/*#Ops*/, 1, 6, // Results = #7 /*1172*/ OPC_EmitConvertToTarget, 5, /*1174*/ OPC_EmitNode, TARGET_VAL(Hexagon::LDriw_indexed), 0|OPFL_Chain, 1/*#VTs*/, MVT::i32, 2/*#Ops*/, 4, 8, // Results = #9 /*1...

Hi, On the hexagon target, I have written a following combiner pattern. ********************************************* def: Pat<(i64 (or (i64 (shl (i64 (extloadi32 (i32 (add IntRegs:$src1, s11_2ExtPred:$offset1)))), (i32 32))), (i64 (zextloadi32 ADDRriS11_2:$src2)))), (i64 (COMBINE_rr

...$op0",mayStore=1, > > Are you sure you mean "mayStore" here and not "mayLoad"? > > > very bad, all uses of input chain was replaced with ADDErm Node. > > Since your ADDErm is also a load, it is going to need an input chain > of some kind (and hence OPFL_Chain) so that's not surprising on its > own. > > > so the created token factor node depends on the ADDErm node after the > > replacement. > > I don't suppose you could post the output of "-view-isel-dags" & > "-view-sched-dags"? I've got so...

...dload > /*2249*/ OPC_CheckPredicate, 6, // Predicate_load > /*2251*/ OPC_CheckType, MVT::i64, > /*2253*/ OPC_EmitMergeInputChains1_0, > /*2254*/ OPC_EmitInteger, MVT::i64, 0, > /*2257*/ OPC_MorphNodeTo, TARGET_VAL(XSTG::LOADI64_RI), > 0|OPFL_Chain|OPFL_MemRefs, > 1/*#VTs*/, MVT::i64, 2/*#Ops*/, 1, 2, > // Src: (ld:i64 (XSTGADDR_NORMAL:iPTR > (tglobaladdr:iPTR):$addr))<<P:Predicate_unindexedload>><<P:Predicate_load>> > - Complexity = 10 > // Ds...

...ctionDAGISel.cpp, but if someone > > has a more-specific idea, I'd appreciate hearing it. > > I believe it's a current TableGen limitation. When generating its DAG > tables for this kind of thing, TableGen gives output instructions that > should take chain a special flag: Opfl_Chain. > > Unfortunately the way it decides which instructions are worthy of this > flag is rather naive: > + If an instruction has a built-in pattern (in the Instruciton > record), it checks whether that makes use of a chain. > + Otherwise, the outer instruction of the Pat get...

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

...this is somewhere in SelectionDAGISel.cpp, but if someone has a > more-specific idea, I'd appreciate hearing it. I believe it's a current TableGen limitation. When generating its DAG tables for this kind of thing, TableGen gives output instructions that should take chain a special flag: Opfl_Chain. Unfortunately the way it decides which instructions are worthy of this flag is rather naive: + If an instruction has a built-in pattern (in the Instruciton record), it checks whether that makes use of a chain. + Otherwise, the outer instruction of the Pat gets a chain. So if your QVLFDXb...

...someone > > > has a more-specific idea, I'd appreciate hearing it. > > > > I believe it's a current TableGen limitation. When generating its > > DAG tables for this kind of thing, TableGen gives output > > instructions that should take chain a special flag: Opfl_Chain. > > > > Unfortunately the way it decides which instructions are worthy of > > this flag is rather naive: > > + If an instruction has a built-in pattern (in the Instruciton > > record), it checks whether that makes use of a chain. > > + Otherwise, the ou...

Working on a target I added this pattern: def : Pat<(v4i64 (load xoaddr:$src)), (QVFCTIDb (QVLFDXb xoaddr:$src))>; which represents an actual load followed by a necessary conversion operation. The problem is that when this matches any TokenFactor that was attached to the load node gets attached, not to the inner load instruction, but the outer conversion operation. This is

.../*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*/, 0/*#Ops*/, // Src: (retflag) - Complexity = 3 // Dst: (RETL) /*4322*/ /*Scope*/ 11, /*->4334*/ /*4323*/ OPC_RecordNode, // #0 = $a /*4324*/ OPC_CheckType, MVT::i32, /*4326*/ OPC_MorphNodeTo, TARGET_VAL...

...ne has a more-specific idea, I'd appreciate hearing it. > > > > > > I believe it's a current TableGen limitation. When generating its > > > DAG tables for this kind of thing, TableGen gives output > > > instructions that should take chain a special flag: Opfl_Chain. > > > > > > Unfortunately the way it decides which instructions are worthy of > > > this flag is rather naive: > > > + If an instruction has a built-in pattern (in the Instruciton > > > record), it checks whether that makes use of a chain. > &...

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

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