[LLVMdev] Bug in InsertElement constant propagation?

[Jonathan Roelofs]

On 1/14/15 9:22 AM, Raoux, Thomas F wrote:
> Hi,
>
> When I run opt on the following LLVM IR:
>
> define i32 @foo() {
>
> bb0:
>
>    %0 = bitcast i32 2139171423 to float
>
>    %1 = insertelement <1 x float> undef, float %0, i32 0
>
>    %2 = extractelement <1 x float> %1, i32 0
>
>    %3 = bitcast float %2 to i32
>
>    ret i32 %3
>
> }
>
> ->
>
> It generates:
>
> define i32 @foo() {
>
> bb0:
>
>    ret i32 2143365727
>
> }
>
> While tracking the value I see that the floating point value is changed
> while folding insertElement into a constant expression.
>
> In Constant.cpp line 902, we convert the APFloat into float then convert
> it back when creating the ConstantDataArray. This causes the float value
> to be changed. I’m not entirely positive why the float value returned by
> converToFloat has a different memory representation than the original
> int value, there must be a C++ rule that I’m missing.
>
> d
>
>      if (ConstantFP *CFP = dyn_cast<ConstantFP>(C)) {
>
>        if (CFP->getType()->isFloatTy()) {
>
>          SmallVector<float, 16> Elts;
>
>          for (unsigned i = 0, e = V.size(); i != e; ++i)
>
>            if (ConstantFP *CFP = dyn_cast<ConstantFP>(V[i]))
>
>              Elts.push_back(CFP->getValueAPF().convertToFloat());
>
>            else
>
>              break;
>
>          if (Elts.size() == V.size())
>
>            return ConstantDataArray::get(C->getContext(), Elts);
>
>        }
>
> Anyone knows what is the problem here?
Both bit patterns are representations of NaN, which IIRC, is not 
required to be preserved when copying a float.


Jon
>
> Cheers,
>
> Thomas
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded