llvm dev - Dec 2018 - [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>

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>

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>