[llvm-dev] FENV_ACCESS and floating point LibFunc calls

[Hal Finkel via llvm-dev]

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>