[llvm-dev] FENV_ACCESS and floating point LibFunc calls

Hal Finkel via llvm-dev
2017-05-10T23:44:40Z

On 05/10/2017 06:17 PM, Kaylor, Andrew via llvm-dev
wrote:
>
> Hi all,
>
> Background
>
> I’ve been working on adding the necessary support to LLVM for clang to
> be able to support the STDC FENV_ACCESS pragma, which basically allows
> users to modify rounding mode at runtime and depend on the value of
> floating-point status flags or to unmask floating point exceptions
> without unexpected side effects.  I’ve committed an initial patch
> (r293226) that adds constrained intrinsics for the basic FP
> operations, and I have a patch up for review now
> (https://reviews.llvm.org/D32319) that adds constrained versions of a
> number of libm-like FP intrinsics.
>
> Current problem
>
> Now I’m trying to make sure I have a good solution for the way in
> which the optimizer handles recognized calls to libm functions (sqrt,
> pow, cos, sin, etc.). Basically, I need to prevent all passes from
> making any modifications to these calls that would make assumptions
> about rounding mode or improperly affect the FP status flags (either
> suppressing flags that should be present or setting flags that should
> not be set).  For instance, there are circumstances in which the
> optimizer will constant fold a call to one of these functions if the
> value of the arguments are known at compile time, but this constant
> folding generally assumes the default rounding mode and if the library
> call would have set a status flag, I need the flag to be set.
>
> Question
>
> My question is, can/should I just rely on the front end setting the
> “nobuiltin” attribute for the call site in any location where the FP
> behavior needs to be restricted?
>

Unless you want to assume that the frontend knows about all functions
that backend knows about, which I don't think we do, I think this will
essentially mean adding nobuiltin to all calls. This is what we do if
you compile using Clang with -fno-builtin or -ffreestanding. This will
work, although it seems better to have a dedicated attribute for this.
no_fp_opts, no_fp_builtin or whatever.

  -Hal

> Ideally, I would like to be able to conditionally enable optimizations
> like constant folding if I am able to prove that the rounding mode,
> though dynamic, is known for the callsite at compile time (the
> constrained intrinsics have a mechanism to enable this), but at the
> moment I am more concerned about correctness and would be willing to
> sacrifice optimizations to get correct behavior.  Long term, I was
> thinking that maybe I could do something like attach metadata to
> indicate rounding mode and exception behavior when they were known.
>
> Is there a better way to do this?
>
> Thanks,
>
> Andy
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> 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/20170510/7c295b80/attachment.html>