[llvm-dev] FENV_ACCESS and floating point LibFunc calls
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Wed May 10 16:44:40 PDT 2017
On 05/10/2017 06:17 PM, Kaylor, Andrew via llvm-dev wrote:
> Hi all,
> 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.
> 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.
> 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?
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev