Krzysztof Parzyszek via llvm-dev
2016-Jan-15 21:10 UTC
[llvm-dev] Expanding a PseudoOp and accessing the DAG
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::TargetGlobalAddress), > /*2245*/ OPC_MoveParent, > /*2246*/ OPC_MoveParent, > /*2247*/ OPC_CheckPredicate, 5, // Predicate_unindexedload > /*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 > // Dst: (LOADI64_RI:i64 (tglobaladdr:i64):$addr, 0:i64) > > Not sure why the initial Opcode index is being set to 0 instead of 2235?That's where matching of ADDR_NORMAL begins. Is the code matching ADDR_USE_GRP in the .inc file? -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Phil Tomson via llvm-dev
2016-Jan-15 21:50 UTC
[llvm-dev] Expanding a PseudoOp and accessing the DAG
On Fri, Jan 15, 2016 at 1:10 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote:> 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::TargetGlobalAddress), >> /*2245*/ OPC_MoveParent, >> /*2246*/ OPC_MoveParent, >> /*2247*/ OPC_CheckPredicate, 5, // Predicate_unindexedload >> /*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 >> // Dst: (LOADI64_RI:i64 (tglobaladdr:i64):$addr, 0:i64) >> >> Not sure why the initial Opcode index is being set to 0 instead of 2235? >> > > That's where matching of ADDR_NORMAL begins. Is the code matching > ADDR_USE_GRP in the .inc file?Oh, sorry, copied the wrong section, yes it's there: /*2266*/ /*SwitchOpcode*/ 35, TARGET_VAL(XSTGISD::ADDR_USE_GRP),// ->2304 /*2269*/ OPC_RecordChild0, // #1 = $addr /*2270*/ OPC_MoveChild, 0, /*2272*/ OPC_CheckOpcode, TARGET_VAL(ISD::TargetGlobalAddress), /*2275*/ OPC_MoveParent, /*2276*/ OPC_MoveParent, /*2277*/ OPC_CheckPredicate, 5, // Predicate_unindexedload /*2279*/ OPC_CheckPredicate, 6, // Predicate_load /*2281*/ OPC_CheckType, MVT::i64, /*2283*/ OPC_EmitMergeInputChains1_0, /*2284*/ OPC_EmitNode, TARGET_VAL(XSTG::MOVIMMZ_I64), 0, 1/*#VTs*/, MVT::i64, 1/*#Ops*/, 1, // Results = #2 /*2292*/ OPC_EmitRegister, MVT::i64, XSTG::GRP, /*2295*/ OPC_MorphNodeTo, TARGET_VAL(XSTG::LOADI64_RR), 0|OPFL_Chain|OPFL_MemRefs, 1/*#VTs*/, MVT::i64, 2/*#Ops*/, 2, 3, // Src: (ld:i64 (XSTGADDR_USE_GRP:iPTR (tglobaladdr:iPTR):$addr))<<P:Predicate_unindexedload>><<P:Predicate_load>> - Complexity = 10 // Dst: (LOADI64_RR:i64 (MOVIMMZ_I64:i64 (tglobaladdr:i64):$addr), GRP:i64) /*2304*/ 0, // EndSwitchOpcode> > > -Krzysztof > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160115/12b5d13d/attachment.html>
Krzysztof Parzyszek via llvm-dev
2016-Jan-18 19:30 UTC
[llvm-dev] Expanding a PseudoOp and accessing the DAG
On 1/15/2016 3:50 PM, Phil Tomson wrote:> > Oh, sorry, copied the wrong section, yes it's there: >I don't know. Could you post the entire output from debug-only=isel? -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation