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

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

On 1/14/15 11:12 AM, Raoux, Thomas F wrote:
> 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 don't know if IR is required to preserve NaN bit patterns, but ISTM 
that it would be better if it did.
> I assume we shouldn't be converting APFloat to float in order to avoid
such problems?
Yes, I think that's the correct fix.

Jon

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

I don't see a way to create a ConstantDataVector from Constant or form
APFloat though. Did I oversee that?
Is the solution to had a new get function in ConstantDataVector to allow that?
Any hint on what would be the right fix otherwise?

Thomas

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



On 1/14/15 11:12 AM, Raoux, Thomas F wrote:
> 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 don't know if IR is required to preserve NaN bit patterns, but ISTM that
it would be better if it did.
> I assume we shouldn't be converting APFloat to float in order to avoid
such problems?
Yes, I think that's the correct fix.

Jon

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