Yan Luo via llvm-dev
2018-Dec-04 18:34 UTC
[llvm-dev] [Unsafe-fp-math] Merge attribute for inlining
Hello dev, I have a question about unsafe-fp-math function attribute. Currently LLVM merges this attribute for inlining with logical AND. That means if caller has this attribute set but callee has not, LLVM will reset this attribute on caller. But shouldn't we respect this attribute on caller? If caller wants to perform unsafe fp operation, any code that gets inlined should be allowed to do unsafe fp operation, right? Thanks! Regards, Yan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181204/7713a0a8/attachment.html>
Finkel, Hal J. via llvm-dev
2018-Dec-04 19:34 UTC
[llvm-dev] [Unsafe-fp-math] Merge attribute for inlining
On 12/4/18 12:34 PM, Yan Luo via llvm-dev wrote: Hello dev, I have a question about unsafe-fp-math function attribute. Currently LLVM merges this attribute for inlining with logical AND. That means if caller has this attribute set but callee has not, LLVM will reset this attribute on caller. But shouldn’t we respect this attribute on caller? If caller wants to perform unsafe fp operation, any code that gets inlined should be allowed to do unsafe fp operation, right? Thanks! The answer, by design, is no. At this point, all frontends should be generating per-instruction fast-math flags, and that should also have the property that the relevant semantics are preserved across inlining. The underlying concern is that, under LTO, code that was compiled without -ffast-math can be inlined into code compiled with -ffast-math, and this combined code must continue to work even when the strict semantics are required for correctness for the code compiled without -ffast-math. -Hal Regards, Yan _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181204/4cbec955/attachment.html>
Yan Luo via llvm-dev
2018-Dec-04 21:28 UTC
[llvm-dev] [Unsafe-fp-math] Merge attribute for inlining
Hal, Thanks for the reply. I am trying to understand the underlying concern. That means the inlining of a callee without unsafe-fp-math attribute set will block the unsafe optimization in its caller, right? Thanks, Yan From: Finkel, Hal J. [mailto:hfinkel at anl.gov] Sent: Tuesday, December 4, 2018 11:34 AM To: Yan Luo <yan.luo2 at synopsys.com>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] [Unsafe-fp-math] Merge attribute for inlining On 12/4/18 12:34 PM, Yan Luo via llvm-dev wrote: Hello dev, I have a question about unsafe-fp-math function attribute. Currently LLVM merges this attribute for inlining with logical AND. That means if caller has this attribute set but callee has not, LLVM will reset this attribute on caller. But shouldn't we respect this attribute on caller? If caller wants to perform unsafe fp operation, any code that gets inlined should be allowed to do unsafe fp operation, right? Thanks! The answer, by design, is no. At this point, all frontends should be generating per-instruction fast-math flags, and that should also have the property that the relevant semantics are preserved across inlining. The underlying concern is that, under LTO, code that was compiled without -ffast-math can be inlined into code compiled with -ffast-math, and this combined code must continue to work even when the strict semantics are required for correctness for the code compiled without -ffast-math. -Hal Regards, Yan _______________________________________________ LLVM Developers mailing list llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMF-g&c=DPL6_X_6JkXFx7AXWqB0tg&r=VP6NpUwuwAXxdCugKYVKOuNr-I2x2_Cx1QkggUmrO9E&m=nJn7JadT9zarm-IAAqWE4edU5XSfeiXyjq-I8JYeBZE&s=uN17xN_M91org9jZEz_RmcsUYibXy91-9nuO0R0UvC8&e=> -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181204/a44add59/attachment-0001.html>