Krzysztof Parzyszek via llvm-dev
2016-Jan-15 20:10 UTC
[llvm-dev] Expanding a PseudoOp and accessing the DAG
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 (MOVIMMZ_I64 tglobaladdr:$addr), GRP)>;Right.> ...at least that gets through TableGen.Excellent. -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 20:57 UTC
[llvm-dev] Expanding a PseudoOp and accessing the DAG
On Fri, Jan 15, 2016 at 12:10 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote:> 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 (MOVIMMZ_I64 tglobaladdr:$addr), GRP)>; >> > > Right. > > > ...at least that gets through TableGen. >> > > Excellent.Actually, I realized that the second should be a LOADI64_RR (reg reg instead of reg immediate). So it's really this: // Match load from a relocatable address to a load with GRP: def: Pat<(load (XSTGADDR_USE_GRP tglobaladdr:$addr)), (LOADI64_RR (MOVIMMZ_I64 tglobaladdr:$addr), GRP)>; When I tried running llc on my example code I get this: ISEL: Starting pattern match on root node: 0x362d630: i64 XSTGISD::ADDR_USE_GRP 0x3628c90 [ORD=10] [ID=29] Initial Opcode index to 0 Match failed at index 0 LLVM ERROR: Cannot select: 0x362d630: i64 = XSTGISD::ADDR_USE_GRP 0x3628c90 [ORD=10] [ID=29] 0x3628c90: i64 = TargetGlobalAddress<i32 addrspace(4)* @answer> 0 [TF=7] [ORD=10] [ID=22] In function: main 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? Phil> > > -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/bad540a7/attachment.html>
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
Reasonably Related Threads
- Expanding a PseudoOp and accessing the DAG
- Expanding a PseudoOp and accessing the DAG
- Failure to match a DAG after a minor pattern change in a custom Target
- Expanding a PseudoOp and accessing the DAG
- BPF backend with vector operations - error "Could not infer all types in, pattern!"