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>
Eli Friedman via llvm-dev
2020-Jul-20 19:57 UTC
[llvm-dev] BitcodeReader.cpp bug under LTO
The issue is specifically the case where the condition of a select constant
expression is itself a select or shuffle constant expression? The simplest
solution is probably to just call getConstantFwdRef() early, to "set"
the type of each expression. We know the result type of the constant expression
when we first see it; the ambiguity is only the type of the condition operand.
-Eli
From: chenmindong <chenmindong1 at huawei.com>
Sent: Sunday, July 19, 2020 10:27 PM
To: Eli Friedman <efriedma at quicinc.com>; llvm-dev at lists.llvm.org
Subject: [EXT] RE: [llvm-dev] BitcodeReader.cpp bug under LTO
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<mailto:chenmindong1 at
huawei.com>>; llvm-dev <llvm-dev at lists.llvm.org<mailto: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/fc8edd34/attachment.html>
I don't have a test case for that special case right now. The problem is
that the code wants to determine condition's type before see it, which is
impossible IIUC, and calling getConstantFwdRef() earlier doesn't help there
because it also requires for a type. I'll commit a patch for the bug I
posted, but more efforts will be needed to solve it thoroughly .
-Mindong
From: Eli Friedman [mailto:efriedma at quicinc.com]
Sent: Tuesday, July 21, 2020 3:57 AM
To: chenmindong <chenmindong1 at huawei.com>; llvm-dev at lists.llvm.org
Subject: RE: [llvm-dev] BitcodeReader.cpp bug under LTO
The issue is specifically the case where the condition of a select constant
expression is itself a select or shuffle constant expression? The simplest
solution is probably to just call getConstantFwdRef() early, to "set"
the type of each expression. We know the result type of the constant expression
when we first see it; the ambiguity is only the type of the condition operand.
-Eli
From: chenmindong <chenmindong1 at huawei.com<mailto:chenmindong1 at
huawei.com>>
Sent: Sunday, July 19, 2020 10:27 PM
To: Eli Friedman <efriedma at quicinc.com<mailto:efriedma at
quicinc.com>>; llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>
Subject: [EXT] RE: [llvm-dev] BitcodeReader.cpp bug under LTO
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<mailto:chenmindong1 at
huawei.com>>; llvm-dev <llvm-dev at lists.llvm.org<mailto: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/20200721/a0166176/attachment.html>