Hi guys, We have found a bug of BitcodeReader.cpp in processing an LTO bitcode file. As LLVM doesn't emit use-list for LTO bitcode files, many forward references will happen when BitcodeReader processes the bitcode file, and LLVM uses placeholders for those forward references and resolve them later. When parseConstants() reads in a CST_CODE_CE_SELECT record, e.g. select <selty><cond>, <ty><val1>, <ty><val2> If "ty" here is a vector type and "cond" is a forward reference, LLVM uses i1 as the placeholder type of "cond" if it cannot find "cond" in ValueList, as the code follows: Type *SelectorTy = Type::getInt1Ty(Context); // The selector might be an i1 or an <n x i1> // Get the type from the ValueList before getting a forward ref. if (VectorType *VTy = dyn_cast<VectorType>(CurTy)) if (Value *V = ValueList[Record[0]]) if (SelectorTy != V->getType()) SelectorTy = VectorType::get(SelectorTy, VTy->getNumElements()); However, the program aborts in RAUW() if we find "selty" is a vector type later, because LLVM are trying to replace an i1 placeholder with an <n x i1> value. A rough idea is to create a BitcodeReader-specific RAUW which doesn't check type legitimacy and any other suggestion is welcome. Bugzilla link: https://bugs.llvm.org/show_bug.cgi?id=46750 Regards, Mindong -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200716/92049cd4/attachment.html>
Eli Friedman via llvm-dev
2020-Jul-16 19:05 UTC
[llvm-dev] BitcodeReader.cpp bug under LTO
The DelayedShuffles code in BitcodeReader::parseConstants is solving a sort of similar issue; you might be able to borrow the same approach. -Eli From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of chenmindong via llvm-dev Sent: Thursday, July 16, 2020 7:54 AM To: llvm-dev at lists.llvm.org Subject: [EXT] [llvm-dev] BitcodeReader.cpp bug under LTO Hi guys, We have found a bug of BitcodeReader.cpp in processing an LTO bitcode file. As LLVM doesn't emit use-list for LTO bitcode files, many forward references will happen when BitcodeReader processes the bitcode file, and LLVM uses placeholders for those forward references and resolve them later. When parseConstants() reads in a CST_CODE_CE_SELECT record, e.g. select <selty><cond>, <ty><val1>, <ty><val2> If "ty" here is a vector type and "cond" is a forward reference, LLVM uses i1 as the placeholder type of "cond" if it cannot find "cond" in ValueList, as the code follows: Type *SelectorTy = Type::getInt1Ty(Context); // The selector might be an i1 or an <n x i1> // Get the type from the ValueList before getting a forward ref. if (VectorType *VTy = dyn_cast<VectorType>(CurTy)) if (Value *V = ValueList[Record[0]]) if (SelectorTy != V->getType()) SelectorTy = VectorType::get(SelectorTy, VTy->getNumElements()); However, the program aborts in RAUW() if we find "selty" is a vector type later, because LLVM are trying to replace an i1 placeholder with an <n x i1> value. A rough idea is to create a BitcodeReader-specific RAUW which doesn't check type legitimacy and any other suggestion is welcome. Bugzilla link: https://bugs.llvm.org/show_bug.cgi?id=46750 Regards, Mindong -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200716/6d0e8dfd/attachment.html>
Hi Eli, Thanks for the advice! By delaying processing the "select" until we have resolved other records(like "aggregate " in this case) as you did for "shuffle", the test case passes now. But I wonder if it's an ultimate solution: what if the selector of a "select" is the output of another forward-reference "select" that hasn't been resolved yet? We still cannot determine its type then. Is it possible? Regards, Mindong From: Eli Friedman [mailto:efriedma at quicinc.com] Sent: Friday, July 17, 2020 3:06 AM To: chenmindong <chenmindong1 at huawei.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: RE: [llvm-dev] BitcodeReader.cpp bug under LTO The DelayedShuffles code in BitcodeReader::parseConstants is solving a sort of similar issue; you might be able to borrow the same approach. -Eli From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of chenmindong via llvm-dev Sent: Thursday, July 16, 2020 7:54 AM To: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> Subject: [EXT] [llvm-dev] BitcodeReader.cpp bug under LTO Hi guys, We have found a bug of BitcodeReader.cpp in processing an LTO bitcode file. As LLVM doesn't emit use-list for LTO bitcode files, many forward references will happen when BitcodeReader processes the bitcode file, and LLVM uses placeholders for those forward references and resolve them later. When parseConstants() reads in a CST_CODE_CE_SELECT record, e.g. select <selty><cond>, <ty><val1>, <ty><val2> If "ty" here is a vector type and "cond" is a forward reference, LLVM uses i1 as the placeholder type of "cond" if it cannot find "cond" in ValueList, as the code follows: Type *SelectorTy = Type::getInt1Ty(Context); // The selector might be an i1 or an <n x i1> // Get the type from the ValueList before getting a forward ref. if (VectorType *VTy = dyn_cast<VectorType>(CurTy)) if (Value *V = ValueList[Record[0]]) if (SelectorTy != V->getType()) SelectorTy = VectorType::get(SelectorTy, VTy->getNumElements()); However, the program aborts in RAUW() if we find "selty" is a vector type later, because LLVM are trying to replace an i1 placeholder with an <n x i1> value. A rough idea is to create a BitcodeReader-specific RAUW which doesn't check type legitimacy and any other suggestion is welcome. Bugzilla link: https://bugs.llvm.org/show_bug.cgi?id=46750 Regards, Mindong -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200720/ac6e7c3b/attachment.html>