Phil Tomson via llvm-dev
2016-Sep-28 19:44 UTC
[llvm-dev] Incompatible type assertion from llvm-tblgen
On Mon, Sep 26, 2016 at 2:24 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote:> On 9/26/2016 3:58 PM, Phil Tomson wrote: > >> But don't the defs for ADDR_RR and ADDR_RI also contain dags? >> >> def ADDR_RR : Addr< 2, "SelectAddrRegReg", >> (ops GPRC:$base, GPRC:$offsetreg) >; >> def ADDR_RI : Addr< 2, "SelectAddrRegImm", >> (ops GPRC:$base, i64imm:$offsetimm) >; >> >> Do I need to create some other intermediate node type for a shifted >> address? >> > > Technically yes, but the list of allowed types is limited. "RegisterClass" > (e.g GPRC) is allowed, as is "Operand" (e.g. i64imm). > > You can create a subclass of "Operand" and provide your EncoderMethod for > it. > > >Followup question: I was thinking that in order to match this DAG: 0x30d29c0: i64 = Constant<3> 0x30d2e00: i64 = shl 0x30d2be0, 0x30d29c0 [ORD=3] 0x30d2f10: i64 = add 0x30d2cf0, 0x30d2e00 [ORD=3] 0x30d28b0: <multiple use> 0x30d3570: i32,ch = load 0x30a3ec0, 0x30d2f10, 0x30d28b0<LD4[%arrayidx16(addrspace=4)](align=8)(tbaa=<0x3082188>)> [ORD=4] And map it to a load.idx instruction with the following semantics: load.idx r1,r2,r3,SIZE r1 <- mem[r2 + (r3 << sizeof(operand))] That somehow the pattern matching dag fragment would need to be something like I had in ADDR_SHLI definition: def ADDR_SHLI : Addr< 2, "SelectAddrShlImm", (ops GPRC:$base, ( shl GPRC:$offsetreg, (i64 3))) >; Now If I have to create a subclass of Operand and define it's EncoderMethod in C++, does that mean the pattern matching (matching the shift left and add) now happens on the C++ side as well? 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/20160928/76993d6e/attachment.html>
Krzysztof Parzyszek via llvm-dev
2016-Sep-28 19:54 UTC
[llvm-dev] Incompatible type assertion from llvm-tblgen
On 9/28/2016 2:44 PM, Phil Tomson wrote:> And map it to a load.idx instruction with the following semantics: > load.idx r1,r2,r3,SIZE r1 <- mem[r2 + (r3 << sizeof(operand))] > > That somehow the pattern matching dag fragment would need to be > something like I had in ADDR_SHLI definition: > def ADDR_SHLI : Addr< 2, "SelectAddrShlImm", > (ops GPRC:$base, ( shl GPRC:$offsetreg, (i64 3))) >; > > > Now If I have to create a subclass of Operand and define it's > EncoderMethod in C++, does that mean the pattern matching (matching the > shift left and add) now happens on the C++ side as well?Actually the EncoderMethod is probably not needed for this case. I thought you had a scaled immediate that needs to be shifted during encoding. Regarding pattern matching in the C++ code---yes, that's what ComplexPattern implies. The function whose name you provide will be used to match the DAG and generate the output. The instruction definition would have 3 inputs: register, register and immediate: def ADDR_SHLI: Addr<3, "SelectAddrShlImm", (ops GPRC:$base, GPRC:$offsetreg, i64imm:$shift)>; The matching function would then need to match DAG and generate these 3 values if the match succeeded. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Phil Tomson via llvm-dev
2016-Oct-04 00:16 UTC
[llvm-dev] Incompatible type assertion from llvm-tblgen
On Wed, Sep 28, 2016 at 12:54 PM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote:> On 9/28/2016 2:44 PM, Phil Tomson wrote: > >> And map it to a load.idx instruction with the following semantics: >> load.idx r1,r2,r3,SIZE r1 <- mem[r2 + (r3 << sizeof(operand))] >> >> That somehow the pattern matching dag fragment would need to be >> something like I had in ADDR_SHLI definition: >> def ADDR_SHLI : Addr< 2, "SelectAddrShlImm", >> (ops GPRC:$base, ( shl GPRC:$offsetreg, (i64 3))) >; >> >> >> Now If I have to create a subclass of Operand and define it's >> EncoderMethod in C++, does that mean the pattern matching (matching the >> shift left and add) now happens on the C++ side as well? >> > > Actually the EncoderMethod is probably not needed for this case. I thought > you had a scaled immediate that needs to be shifted during encoding. > > Regarding pattern matching in the C++ code---yes, that's what > ComplexPattern implies. The function whose name you provide will be used to > match the DAG and generate the output. > > The instruction definition would have 3 inputs: register, register and > immediate: > > def ADDR_SHLI: Addr<3, "SelectAddrShlImm", > (ops GPRC:$base, GPRC:$offsetreg, i64imm:$shift)>; > > The matching function would then need to match DAG and generate these 3 > values if the match succeeded.What I'm finding is that the matching function for 3 arguments (the SelectAddrShlImm) is never tried for this particular case. This one is tried: def ADDR_RR : Addr< 2, "SelectAddrRegReg", (ops GPRC:$base, GPRC:$offsetreg) >; I've added some debugging statements to show some of the output from llc with -debug below: 0x2385bb0: i64,ch = load 0x2356e90, 0x2388b60, 0x2385880<LD8[getelementptr ([0 x i64] addrspace(2)* @SpM_use_row, i64 0, i64 undef)(addrspace=2)](tbaa=<0x2335188>)> [ORD=2] [ID=12] 0x2385990: i64 = Constant<3> [ID=2] 0x2385dd0: i64 = shl 0x2385bb0, 0x2385990 [ORD=3] [ID=13] 0x2385ee0: i64 = add 0x2386650, 0x2385dd0 [ORD=3] [ID=14] 0x2385880: <multiple use> *0x2386540*: i32,ch = load 0x2356e90, 0x2385ee0, 0x2385880<LD4[%arrayidx16(addrspace=4)](align=8)(tbaa=<0x2335188>)> [ORD=4] [ID=15] 0x2386320: ch,glue = CopyToReg 0x2356e90, 0x2386210, 0x2386540 [ORD=6] 0x2386210: <multiple use> 0x2386320: <multiple use> 0x2386320: <multiple use> 0x2386430: ch = RET 0x2386210, 0x2386320, 0x2386320:1 [ORD=6] SelectAddrRegReg called: *0x2386540:* i32,ch = load 0x2356e90, 0x2385ee0, 0x2385880<LD4[%arrayidx16(addrspace=4)](align=8)(tbaa=<0x2335188>)> [ORD=4] [ID=15] SelectAddrRegRegCommon called: Morphed node: 0x2386540: i32,ch = LOADI32_RR 0x2386650, 0x2385dd0, 0x2356e90<Mem:LD4[%arrayidx16(addrspace=4)](align=8)(tbaa=<0x2335188>)> [ORD=4] ISEL: Match complete! If I set a breakpoint in SelectAddrRegRegCommon I can see that this is true: gdb> p Addr.getOperand(1).Node->getOpcode() == ISD::SHL) true So I've added that as a case to check for there, here's the function: bool XSTGDAGToDAGISel::SelectAddrRegRegCommon( SDValue Addr, SDValue &Base, SDValue &Offset ) { // If add operation, we can optimize. DEBUG(errs() << "SelectAddrRegRegCommon called: \n"); if (Addr.getOpcode() == ISD::ADD) { if (Addr.getOperand(0).getOpcode() == ISD::TargetJumpTable) {` Base = Addr.getOperand(0); Offset = Addr.getOperand(1); return true; } if (Addr.getOperand(1).getOpcode() == ISD::TargetJumpTable) { Base = Addr.getOperand(1); Offset = Addr.getOperand(0); return true; } // operand 1 can't be a constant. if (dyn_cast<ConstantSDNode>(Addr.getOperand(1))) { return false; } //possibly a load.idx if(Addr.getOperand(1).Node->getOpcode() == ISD::SHL) { // Not sure what should go here? } // set address and offset. Base = Addr.getOperand(0); Offset = Addr.getOperand(1); return true; } return false; } //end SelectAddrRegRegCommon As the comment says, I'm not sure what code should go into the case where it's possibly a load.idx - Base and Offset are SDValues not SDNodes so I don't see how I could modify the DAG here to eliminate the shl - any ideas? 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/20161003/42a0ec88/attachment.html>