SANGEETA CHOWDHARY via llvm-dev
2018-Aug-11 20:15 UTC
[llvm-dev] Need help in understanding llvm optimization
I am sorry to not make my question clear. My question is how this value is calculated without having fadd and fsub in IR? On Sat, Aug 11, 2018 at 4:06 PM, Craig Topper <craig.topper at gmail.com> wrote:> Neither 1e16 or 1e16+1 can be accurately represented in a double. The > largest integer than be accurately represented is 2^53. As the number gets > larger floating sacrifices precision in the lower digits. Because of this > 1e16 and 1e16+1 end up having the same representation. So the result of > subtracting them is 0.0. > > On Sat, Aug 11, 2018 at 12:30 PM SANGEETA CHOWDHARY via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> I have below code in C - >> >> int main() { >> >> double x,y; >> >> x = 1e16; >> >> y = (x + 1) - x; >> >> printf("y:%e\n", y); >> >> return 0; >> >> } >> >> llvm bitcode looks like this for this function - >> >> >> ; Function Attrs: nounwind uwtable >> >> define dso_local i32 @main() local_unnamed_addr #0 { >> >> entry: >> >> %call = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 >> x i8], [4 x i8]* @.str, i64 0, i64 0), double 0.000000e+00) >> >> ret i32 0 >> >> } >> >> I am not able to understand how addition and subtraction are performed in >> this code. There is no fadd or fsub instruction. How llvm knows that result >> of y is 0? >> >> Is there any way to disable this in llvm? >> >> >> Any help would be much appreciated. >> >> >> Regards, >> >> Sangeeta >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > -- > ~Craig >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180811/07efab21/attachment-0001.html>
Craig Topper via llvm-dev
2018-Aug-11 20:30 UTC
[llvm-dev] Need help in understanding llvm optimization
The compiler constant folded it as an optimization. Was this compiled with optimization’s enabled? On Sat, Aug 11, 2018 at 1:15 PM SANGEETA CHOWDHARY < sc1696 at scarletmail.rutgers.edu> wrote:> I am sorry to not make my question clear. My question is how this value is > calculated without having fadd and fsub in IR? > > On Sat, Aug 11, 2018 at 4:06 PM, Craig Topper <craig.topper at gmail.com> > wrote: > >> Neither 1e16 or 1e16+1 can be accurately represented in a double. The >> largest integer than be accurately represented is 2^53. As the number gets >> larger floating sacrifices precision in the lower digits. Because of this >> 1e16 and 1e16+1 end up having the same representation. So the result of >> subtracting them is 0.0. >> >> On Sat, Aug 11, 2018 at 12:30 PM SANGEETA CHOWDHARY via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi, >>> >>> I have below code in C - >>> >>> int main() { >>> >>> double x,y; >>> >>> x = 1e16; >>> >>> y = (x + 1) - x; >>> >>> printf("y:%e\n", y); >>> >>> return 0; >>> >>> } >>> >>> llvm bitcode looks like this for this function - >>> >>> >>> ; Function Attrs: nounwind uwtable >>> >>> define dso_local i32 @main() local_unnamed_addr #0 { >>> >>> entry: >>> >>> %call = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([ >>> 4 x i8], [4 x i8]* @.str, i64 0, i64 0), double 0.000000e+00) >>> >>> ret i32 0 >>> >>> } >>> >>> I am not able to understand how addition and subtraction are performed >>> in this code. There is no fadd or fsub instruction. How llvm knows that >>> result of y is 0? >>> >>> Is there any way to disable this in llvm? >>> >>> >>> Any help would be much appreciated. >>> >>> >>> Regards, >>> >>> Sangeeta >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> -- >> ~Craig >> > > --~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180811/702bb025/attachment.html>
SANGEETA CHOWDHARY via llvm-dev
2018-Aug-11 20:31 UTC
[llvm-dev] Need help in understanding llvm optimization
Yes, with O1. Is there any way to disable constant folding for floating point computations? On Sat, Aug 11, 2018, 4:30 PM Craig Topper <craig.topper at gmail.com> wrote:> The compiler constant folded it as an optimization. Was this compiled with > optimization’s enabled? > > On Sat, Aug 11, 2018 at 1:15 PM SANGEETA CHOWDHARY < > sc1696 at scarletmail.rutgers.edu> wrote: > >> I am sorry to not make my question clear. My question is how this value >> is calculated without having fadd and fsub in IR? >> >> On Sat, Aug 11, 2018 at 4:06 PM, Craig Topper <craig.topper at gmail.com> >> wrote: >> >>> Neither 1e16 or 1e16+1 can be accurately represented in a double. The >>> largest integer than be accurately represented is 2^53. As the number gets >>> larger floating sacrifices precision in the lower digits. Because of this >>> 1e16 and 1e16+1 end up having the same representation. So the result of >>> subtracting them is 0.0. >>> >>> On Sat, Aug 11, 2018 at 12:30 PM SANGEETA CHOWDHARY via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> Hi, >>>> >>>> I have below code in C - >>>> >>>> int main() { >>>> >>>> double x,y; >>>> >>>> x = 1e16; >>>> >>>> y = (x + 1) - x; >>>> >>>> printf("y:%e\n", y); >>>> >>>> return 0; >>>> >>>> } >>>> >>>> llvm bitcode looks like this for this function - >>>> >>>> >>>> ; Function Attrs: nounwind uwtable >>>> >>>> define dso_local i32 @main() local_unnamed_addr #0 { >>>> >>>> entry: >>>> >>>> %call = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds >>>> ([4 x i8], [4 x i8]* @.str, i64 0, i64 0), double 0.000000e+00) >>>> >>>> ret i32 0 >>>> >>>> } >>>> >>>> I am not able to understand how addition and subtraction are performed >>>> in this code. There is no fadd or fsub instruction. How llvm knows that >>>> result of y is 0? >>>> >>>> Is there any way to disable this in llvm? >>>> >>>> >>>> Any help would be much appreciated. >>>> >>>> >>>> Regards, >>>> >>>> Sangeeta >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> -- >>> ~Craig >>> >> >> -- > ~Craig >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180811/04945567/attachment.html>