llvm dev - May 2017 - FENV_ACCESS and floating point LibFunc calls

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?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170510/c1248840/attachment.html>

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>

>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.

Other than that, will this approach solve my problem?

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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170510/f7edb700/attachment.html>