[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