Fix a bug in the 'store fpimm, ptr' -> 'store intimm, ptr' handling code.

Changing 'op' here caused us to not enter the store into a map, causing
reemission of the code!!  In practice, a simple loop like this:

no_exit:                ; preds = %no_exit, %entry
        %indvar = phi uint [ %indvar.next, %no_exit ], [ 0, %entry ]            ; <uint> [#uses=3]
        %tmp.4 = getelementptr "complex long double"* %P, uint %indvar, uint 0          ; <double*> [#uses=1]
        store double 0.000000e+00, double* %tmp.4
        %indvar.next = add uint %indvar, 1              ; <uint> [#uses=2]
        %exitcond = seteq uint %indvar.next, %N         ; <bool> [#uses=1]
        br bool %exitcond, label %return, label %no_exit

was being code gen'd to:

.LBBtest_1:     # no_exit
        movl %edx, %esi
        shll $4, %esi
        movl $0, 4(%eax,%esi)
        movl $0, (%eax,%esi)
        incl %edx
        movl $0, (%eax,%esi)
        movl $0, 4(%eax,%esi)
        cmpl %ecx, %edx
        jne .LBBtest_1  # no_exit

Note that we are doing 4 32-bit stores instead of 2.  Now we generate:

.LBBtest_1:     # no_exit
        movl %edx, %esi
        incl %esi
        shll $4, %edx
        movl $0, (%eax,%edx)
        movl $0, 4(%eax,%edx)
        cmpl %ecx, %esi
        movl %esi, %edx
        jne .LBBtest_1  # no_exit

This is much happier, though it would be even better if the increment of ESI
was scheduled after the compare :-/

llvm-svn: 20265
This commit is contained in:
Chris Lattner 2005-02-22 07:23:39 +00:00
parent 5ab3986e49
commit a474313902
1 changed files with 1 additions and 2 deletions

View File

@ -515,8 +515,7 @@ SDOperand SelectionDAGLegalize::LegalizeOp(SDOperand Op) {
Result = DAG.getNode(ISD::STORE, MVT::Other, Tmp1,
DAG.getConstant(V.I, MVT::i64), Tmp2);
}
Op = Result;
Node = Op.Val;
Node = Result.Val;
}
switch (getTypeAction(Node->getOperand(1).getValueType())) {