Displaying 2 results from an estimated 2 matches for "un17xn_m91org9jzez_rmcsuyibxy91".
2018 Dec 04
2
[Unsafe-fp-math] Merge attribute for inlining
....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/a...
2018 Dec 04
2
[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