Raoux, Thomas F
2015-Jan-14 16:22 UTC
[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>
Jonathan Roelofs
2015-Jan-14 17:38 UTC
[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
Raoux, Thomas F
2015-Jan-14 18:12 UTC
[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