[llvm-dev] FENV_ACCESS and floating point LibFunc calls

[Hal Finkel via llvm-dev]

On 05/10/2017 06:57 PM, Kaylor, Andrew wrote:
>
> >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.
>
> I considered the idea of an FP-specific attribute anyway, because 
> eventually I think I’ll want to do things with these calls that 
> nobuiltins really should be disallowing.  It hadn’t occurred to me 
> that the front end doesn’t know which calls we might be tinkering 
> with.  I guess I was assuming that we’d add something to the front end 
> to recognize the FP library calls, but I can understand why we might 
> want to not do that.
>

Yea, I don't think we want that coupling. We obviously do know the 
standard C ones, but the backend can recognize all sorts of things.

> Other than that, will this approach solve my problem?
>

Yes. I believe that it will.

> Apart from the existing intrinsics (which I believe the front end uses 
> for builtins?) and LibFunc handling, are there other cases I need to 
> be thinking about?
>

I think that should be everything.

  -Hal

> Thanks,
>
> Andy
>
> *From:*Hal Finkel [mailto:hfinkel at anl.gov]
> *Sent:* Wednesday, May 10, 2017 4:45 PM
> *To:* Kaylor, Andrew <andrew.kaylor at intel.com>; llvm-dev 
> <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] FENV_ACCESS and floating point LibFunc calls
>
> 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 <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

-- 
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/4c219e67/attachment.html>