[llvm-dev] Incompatible type assertion from llvm-tblgen
Phil Tomson via llvm-dev
llvm-dev at lists.llvm.org
Tue Oct 4 13:41:52 PDT 2016
On Tue, Oct 4, 2016 at 12:07 PM, Tim Northover <t.p.northover at gmail.com>
wrote:
> On 3 October 2016 at 17:16, Phil Tomson via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > 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?
>
> The shift-handling code would go into a different complex pattern that
> only ever applied to the instruction variant that did the shift
> (SelectAddrShlImm in your case by the looks of it).
>
Yeah, that's what I tried initially. But that pattern never even gets
tested for that particular load. Some of that code is posted below in this
thread, but here i'll post the CheckComplexPattern from the
TargetGenDAGISel.inc:
bool CheckComplexPattern(SDNode *Root, SDNode *Parent,
SDValue N, unsigned PatternNo,
SmallVectorImpl<std::pair<SDValue, SDNode*> > &Result) override {
unsigned NextRes = Result.size();
switch (PatternNo) {
default: llvm_unreachable("Invalid pattern # in table?");
case 0:
Result.resize(NextRes+3);
return SelectAddrShlImm(Parent, N, Result[NextRes+0].first,
Result[NextRes+1].first, Result[NextRes+2].first);
case 1:
Result.resize(NextRes+2);
return SelectAddrRegReg(Parent, N, Result[NextRes+0].first,
Result[NextRes+1].first);
case 2:
Result.resize(NextRes+2);
return SelectAddrRegImm(Parent, N, Result[NextRes+0].first,
Result[NextRes+1].first);
case 3:
Result.resize(NextRes+1);
return SelectAddrImmLocal(Parent, N, Result[NextRes+0].first);
case 4:
Result.resize(NextRes+1);
return SelectAddrRegAny(Parent, N, Result[NextRes+0].first);
}
}
Case 0 isn't even tried for this part of the DAG (PatternNo is 1 so it goes
directly to case 1). Meaning that SelectAdrShlImm isn't called for it.
This is the relevant part of the DAG:
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]
So it morphs it into a LOADI32_RR which isn't what I'd like it to do... I'm
not sure what I'm missing - do I need to try to match a bigger piece of the
DAG, or something? (which I tried to do earlier (see early part of the
thread), but that didnt' work out for other reasons)
Phil
>
> You don't need to actually change the DAG here, just set the Base and
> Offset parameters correctly (after checking the shift amount matches
> too!). The generic code will use those operands instead of the SHL in
> the selected instruction, and if the SHL ends up unused (often the
> case, but not always since a value can be used multiple times) it'll
> just be dropped for the final output.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161004/17776d33/attachment.html>
More information about the llvm-dev
mailing list