llvm dev - Jan 2015 - [LLVMdev] Bug in InsertElement constant propagation?

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?

Cheers,
Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/18f1ee55/attachment.html>

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

Ha here is what I was missing. Thanks Jon. It still seems to me that the
transformation of LLVM IR is invalid is that right? I assume we shouldn't be
converting APFloat to float in order to avoid such problems?

-----Original Message-----
From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] 
Sent: Wednesday, January 14, 2015 9:39 AM
To: Raoux, Thomas F; LLVM Developers Mailing List
Subject: Re: [LLVMdev] Bug in InsertElement constant propagation?



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