[LLVMdev] Possible DAGCombiner or TargetData Bug
David Greene
dag at cray.com
Wed Feb 18 16:49:38 PST 2009
I got bit by this in LLVM 2.4 DagCombiner.cpp and it's still in trunk:
SDValue DAGCombiner::visitSTORE(SDNode *N) {
[...]
// If this is a store of a bit convert, store the input value if the
// resultant store does not need a higher alignment than the original.
if (Value.getOpcode() == ISD::BIT_CONVERT && !ST->isTruncatingStore() &&
ST->isUnindexed()) {
unsigned Align = ST->getAlignment();
MVT SVT = Value.getOperand(0).getValueType();
unsigned OrigAlign = TLI.getTargetData()->
getABITypeAlignment(SVT.getTypeForMVT());
if (Align <= OrigAlign &&
((!LegalOperations && !ST->isVolatile()) ||
TLI.isOperationLegalOrCustom(ISD::STORE, SVT)))
return DAG.getStore(Chain, N->getDebugLoc(), Value.getOperand(0),
Ptr, ST->getSrcValue(),
ST->getSrcValueOffset(), ST->isVolatile(),
OrigAlign);
}
Uhh...this doesn't seem legal to me. How can we just willy-nilly create a
store with a greater alignment? In this case Align is 8 and OrigAlign is 16
because SVT.getTypeForMVT() is Type::VectorTyID (<2 x i64>) which has an ABI
type of VECTOR_ALIGN.
Hmm...why is the ABI alignment for VectorTyID 16? The ABI certainly doesn't
guarantee it. It only guarantees it for __int128, __float128 and __m128.
Lots of other types can map to <2 x i64>.
Any opinions on this?
-Dave
More information about the llvm-dev
mailing list