[LLVMbugs] [Bug 21549] New: Assertion failed: (Op.getValueType() == MVT::f16 && "Inconsistent bitcast? Only 16-bit types should be i16 or f16"), function ReplaceBITCASTResults
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Wed Nov 12 11:18:50 PST 2014
http://llvm.org/bugs/show_bug.cgi?id=21549
Bug ID: 21549
Summary: Assertion failed: (Op.getValueType() == MVT::f16 &&
"Inconsistent bitcast? Only 16-bit types should be i16
or f16"), function ReplaceBITCASTResults
Product: libraries
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Backend: AArch64
Assignee: unassignedbugs at nondot.org
Reporter: grosbach at apple.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 13327
--> http://llvm.org/bugs/attachment.cgi?id=13327&action=edit
llvm-stress testcase
Vector types that end up 16-bits in size break that assertion.
(lldb) p N->dumpr()
0x104ccdc08: i16 = bitcast [ORD=3] [ID=0] 0x104ccdb00
0x104ccdb00: v16i1 = vector_shuffle<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0> [ORD=3]
[ID=-3] 0x104ccd8f0, 0x10404af18: v16i1 = undef [ID=-3]
Context is:
static void ReplaceBITCASTResults(SDNode *N, SmallVectorImpl<SDValue> &Results,
SelectionDAG &DAG) {
if (N->getValueType(0) != MVT::i16)
return;
SDLoc DL(N);
SDValue Op = N->getOperand(0);
assert(Op.getValueType() == MVT::f16 &&
"Inconsistent bitcast? Only 16-bit types should be i16 or f16");
Op = SDValue(
DAG.getMachineNode(TargetOpcode::INSERT_SUBREG, DL, MVT::f32,
DAG.getUNDEF(MVT::i32), Op,
DAG.getTargetConstant(AArch64::hsub, MVT::i32)),
0);
Op = DAG.getNode(ISD::BITCAST, DL, MVT::i32, Op);
Results.push_back(DAG.getNode(ISD::TRUNCATE, DL, MVT::i16, Op));
}
Using an insert_subreg w/ a vector type (especially a non-legal one like v16i1)
is likely to go extremely poorly. Somewhere earlier we've done some custom
lowering that results in this bitcast. Either that code shouldn't be doing that
at all (likely) or this code needs to know how to deal with vectors that end up
16 bits in size. One could probably construct a testcase from v2i8 here as well
to avoid the oddness of vectors of i1.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141112/4318a8a4/attachment.html>
More information about the llvm-bugs
mailing list