[llvm-dev] Tablegen PAT limitation?
Celine via llvm-dev
llvm-dev at lists.llvm.org
Tue Nov 19 20:07:05 PST 2019
Hi,
The full trace stack:
Type set is empty for each HW mode:
possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records).
vtInt: (vt:{ *:[Other] })
UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824!
[ 85%] Building X86GenEVEX2VEXTables.inc...
#0 0x000000000081b9b5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) /home/nancy/work/rpp_clang/llvm/lib/Support/Unix/Signals.inc:495:0
#1 0x000000000081ba48 PrintStackTraceSignalHandler(void*) /home/nancy/work/rpp_clang/llvm/lib/Support/Unix/Signals.inc:559:0
#2 0x0000000000819602 llvm::sys::RunSignalHandlers() /home/nancy/work/rpp_clang/llvm/lib/Support/Signals.cpp:69:0
#3 0x000000000081b3b0 SignalHandler(int) /home/nancy/work/rpp_clang/llvm/lib/Support/Unix/Signals.inc:358:0
fcdsaa #4 0x00007f16408a6390 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x11390)
#5 0x00007f163fa36428 gsignal /build/glibc-LK5gWL/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
#6 0x00007f163fa3802a abort /build/glibc-LK5gWL/glibc-2.23/stdlib/abort.c:91:0
#7 0x0000000000797d00 bindingsErrorHandler(void*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) /home/nancy/work/rpp_clang/llvm/lib/Support/ErrorHandling.cpp:231:0
#8 0x00000000004838a8 llvm::TypeInfer::ValidateOnExit::~ValidateOnExit() /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:826:0
#9 0x00000000004808bd llvm::TypeInfer::EnforceSmallerThan(llvm::TypeSetByHwMode&, llvm::TypeSetByHwMode&) /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:455:0
#10 0x000000000048860f llvm::SDTypeConstraint::ApplyTypeConstraint(llvm::TreePatternNode*, llvm::SDNodeInfo const&, llvm::TreePattern&) const /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:1506:0
#11 0x00000000004a780b llvm::SDNodeInfo::ApplyTypeConstraints(llvm::TreePatternNode*, llvm::TreePattern&) const /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.h:1307:0
#12 0x000000000048e303 llvm::TreePatternNode::ApplyTypeConstraints(llvm::TreePattern&, bool) /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:2362:0
#13 0x000000000048e2d4 llvm::TreePatternNode::ApplyTypeConstraints(llvm::TreePattern&, bool) /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:2361:0
#14 0x000000000048e2d4 llvm::TreePatternNode::ApplyTypeConstraints(llvm::TreePattern&, bool) /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:2361:0
#15 0x000000000048e2d4 llvm::TreePatternNode::ApplyTypeConstraints(llvm::TreePattern&, bool) /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:2361:0
#16 0x00000000005b3c06 (anonymous namespace)::MatcherGen::InferPossibleTypes(unsigned int) /home/nancy/work/rpp_clang/llvm/utils/TableGen/DAGISelMatcherGen.cpp:184:0
#17 0x00000000005b59ca (anonymous namespace)::MatcherGen::EmitMatchCode(llvm::TreePatternNode const*, llvm::TreePatternNode*, unsigned int) /home/nancy/work/rpp_clang/llvm/utils/TableGen/DAGISelMatcherGen.cpp:491:0
#18 0x00000000005b54ba (anonymous namespace)::MatcherGen::EmitOperatorMatchCode(llvm::TreePatternNode const*, llvm::TreePatternNode*, unsigned int) /home/nancy/work/rpp_clang/llvm/utils/TableGen/DAGISelMatcherGen.cpp:440:0
#19 0x00000000005b5c9c (anonymous namespace)::MatcherGen::EmitMatchCode(llvm::TreePatternNode const*, llvm::TreePatternNode*, unsigned int) /home/nancy/work/rpp_clang/llvm/utils/TableGen/DAGISelMatcherGen.cpp:515:0
#20 0x00000000005b6271 (anonymous namespace)::MatcherGen::EmitMatcherCode(unsigned int) /home/nancy/work/rpp_clang/llvm/utils/TableGen/DAGISelMatcherGen.cpp:559:0
#21 0x00000000005b8f4a llvm::ConvertPatternToMatcher(llvm::PatternToMatch const&, unsigned int, llvm::CodeGenDAGPatterns const&) /home/nancy/work/rpp_clang/llvm/utils/TableGen/DAGISelMatcherGen.cpp:1026:0
#22 0x000000000059db91 (anonymous namespace)::DAGISelEmitter::run(llvm::raw_ostream&) /home/nancy/work/rpp_clang/llvm/utils/TableGen/DAGISelEmitter.cpp:169:0
#23 0x000000000059dd1b llvm::EmitDAGISel(llvm::RecordKeeper&, llvm::raw_ostream&) /home/nancy/work/rpp_clang/llvm/utils/TableGen/DAGISelEmitter.cpp:187:0
#24 0x00000000007357d1 (anonymous namespace)::LLVMTableGenMain(llvm::raw_ostream&, llvm::RecordKeeper&) /home/nancy/work/rpp_clang/llvm/utils/TableGen/TableGen.cpp:170:0
#25 0x000000000085c5b8 llvm::TableGenMain(char*, bool (*)(llvm::raw_ostream&, llvm::RecordKeeper&)) /home/nancy/work/rpp_clang/llvm/lib/TableGen/Main.cpp:106:0
#26 0x0000000000735f0c main /home/nancy/work/rpp_clang/llvm/utils/TableGen/TableGen.cpp:253:0
#27 0x00007f163fa21830 __libc_start_main /build/glibc-LK5gWL/glibc-2.23/csu/../csu/libc-start.c:325:0
#28 0x0000000000407bd9 _start (../../../bin/llvm-tblgen+0x407bd9)
===========================================================
PATTERN: (st v1i16:{ *:[v1i16] }:$rs1, (add:{ *:[v1i32] } (shl:{ *:[v1i32] } (sext:{ *:[v1i32] } v1i16:{ *:[v1i16] }:$roffset), (build_vector:{ *:[v1i32] } (imm:{ *:[i32] })<<P:Predicate_uimm2>>:$rshift)), (bitconvert:{ *:[v1i32] } i32:{ *:[i32] }:$rbase)))<<P:Predicate_unindexedstore>><<P:Predicate_store>>
RESULT: (STOREbos v1i16:{ *:[v1i16] }:$rs1, i32:{ *:[i32] }:$rbase, v1i16:{ *:[v1i16] }:$roffset, (imm:{ *:[i32] }):$rshift)
DAGIselMatcherGen.cpp: 559
Pattern.getSrcPattern()->dump();
// list<dag> Pattern = [(store v1i16:$rs1, (add (v1i32 (bitconvert i32:$rbase)), (shl (v1i32 (sext v1i16:$roffset)), (v1i32 (build_vector uimm2:$rshift)))))];
In CodeGenDAGPatterns.cpp: 1443
bool SDTypeConstraint::ApplyTypeConstraint(TreePatternNode *N,
const SDNodeInfo &NodeInfo,
TreePattern &TP) const {
.....
N->dump() ; // (sext:{ *:[v1i32] } v1i16:{ *:[i16] }:$roffset)
Why it become v1i16:{ *:[i16] }:$roffset? Should be (sext:{ *:[v1i32] } v1i16:{ *:[v1i16] }:$roffset) as the Pattern defined.
case SDTCisOpSmallerThanOp: {
unsigned BResNo = 0;
TreePatternNode *BigOperand =
getOperandNum(x.SDTCisOpSmallerThanOp_Info.BigOperandNum, N, NodeInfo,
BResNo);
NodeToApply->dump(); //v1i16:{ *:[i16] }:$roffset
BigOperand->dump(); //(sext:{ *:[v1i32] } v1i16:{ *:[i16] }:$roffset)
return TI.EnforceSmallerThan(NodeToApply->getExtType(ResNo),
BigOperand->getExtType(BResNo));
}
bool TypeInfer::EnforceSmallerThan(TypeSetByHwMode &Small,
TypeSetByHwMode &Big) {
Small->dump(); //{ *:[i16] }
Big->dump(); // { *:[v1i32] }
....
if (none_of(S, isVector) || none_of(B, isVector)) {
Changed |= berase_if(S, isVector) |
berase_if(B, isVector);
}
Changed turn to True here which trigger the final error assert.
How to understand Pattern Match process? Any document?
------------------ Original ------------------
From: "Krzysztof Parzyszek"<kparzysz at quicinc.com>;
Date: Tue, Nov 19, 2019 10:09 PM
To: "Celine"<595602881 at qq.com>;"llvm-dev at lists.llvm.org"<llvm-dev at lists.llvm.org>;
Subject: RE: [llvm-dev] Tablegen PAT limitation?
Hi,
The problem is with a pattern that has a vt in it: the “vtInt …” printed below the error message. Could you run llvm-tblgen from a debugger and show the stack trace from where the error occurred?
--
Krzysztof Parzyszek kparzysz at quicinc.com AI tools development
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Celine via llvm-dev
Sent: Tuesday, November 19, 2019 6:52 AM
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] [llvm-dev] Tablegen PAT limitation?
Hello,
def GPR : RegisterClass<"ABC", [v1i16, v1f16], 16, (add
IA, IB, IC, ID, IE, IF, IG, IH
)>;
def MGPR : RegisterClass<"ABC", [v1i16, v1f16], 16, (add
IA, IB, IC, ID, IE, IF, IG, IH
)>;
def SGPR32 : RegisterClass<"ABC", [ i32, f32 ], 32, (add
DS0, DS1, DS2, DS3, DS4, DS5, DS6, DS7, DS8, DS9, DS10,DS11,
DS12, DS13, DS14, DS15
)>;
def uimm2 : Operand<i32>, ImmLeaf<i32, [{return isUInt<2>(Imm);}]> {
let ParserMatchClass = UImmAsmOperand<2>;
let DecoderMethod = "decodeUImmOperand<2>";
}
possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records).
vtInt: (vt:{ *:[Other] })
UNREACHABLE executed at /home/nancy/rpp_llvm/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824!
def LOADbos { // Instruction ABCInst ABCInstMMEMrr
field bits<32> Inst = { 0, 0, 0, 0, rs1{2}, rs1{1}, rs1{0}, index{0}, 0, 0, 0, 1, 0, rbase{3}, rbase{2}, rbase{1}, rbase{0}, rbase{4}, roffset{4}, roffset{3}, roffset{2}, roffset{1}, roffset{0}, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
field bits<32> SoftFail = { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
string Namespace = "ABC";
dag OutOperandList = (outs GPR:$rs1);
dag InOperandList = (ins SGPR32:$rbase, MGPR:$roffset, uimm2:$rshift);
string AsmString = "LOAD [$rbase + ( $roffset << $rshift )], $rs1";
list<dag> Pattern = [(set v1i16:$rs1, (load (add (v1i32 (bitconvert i32:$rbase)), (shl (v1i32 (sext v1i16:$roffset)), (v1i32 (build_vector uimm2:$rshift))))))];
list<Register> Uses = [];
list<Register> Defs = [];
list<Predicate> Predicates = [];
-gen-dag-isel -debug
PATTERN: (ld:{ *:[v1i16] } (add:{ *:[v1i32] } (shl:{ *:[v1i32] } (sext:{ *:[v1i32] } v1i16:{ *:[v1i16] }:$roffset), (build_vector:{ *:[v1i32] } (imm:{ *:[i32] })<<P:Predicate_uimm2>>:$rshift)), (bitconvert:{ *:[v1i32] } i32:{ *:[i32] }:$rbase)))<<P:Predicate_unindexedload>><<P:Predicate_load>>
RESULT: (LOADbos:{ *:[v1i16] } i32:{ *:[i32] }:$rbase, v1i16:{ *:[v1i16] }:$roffset, (imm:{ *:[i32] }):$rshift)
PATTERN: (st v1i16:{ *:[v1i16] }:$rs1, (add:{ *:[v1i32] } v1i32:{ *:[v1i32] }:$roffset, (bitconvert:{ *:[v1i32] } i32:{ *:[i32] }:$rbase)))<<P:Predicate_unindexedstore>><<P:Predicate_store>>
RESULT: (STORErr v1i16:{ *:[v1i16] }:$rs1, i32:{ *:[i32] }:$rbase, v1i32:{ *:[v1i32] }:$roffset)
Type set is empty for each HW mode:
possible type contradiction in the pattern below (use -print-records with llvm-tblgen to see all expanded records).
vtInt: (vt:{ *:[Other] })
UNREACHABLE executed at /home/nancy/work/rpp_clang/llvm/utils/TableGen/CodeGenDAGPatterns.cpp:824!
Any idea to solve this problem?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191120/6ea3a905/attachment.html>
More information about the llvm-dev
mailing list