llvm dev - Sep 2013 - [LLVMdev] [RFC] New function attributes for errno-setting functions

----- Original Message -----
> 
> Food for thought: If you have a codebase which can't use
> -fno-math-errno, because it relies on errno values from math
> functions, it may be a more effective long-term strategy to work on
> modernizing your codebase, eliminating the dependencies on errno,
> rather than going through the trouble of adding even more complexity
> to compilers to keep errno support limping along.
> 
Wouldn't that require 'modernizing' POSIX? ;) How else can you get
the error code from open() or any number of other functions?

 -Hal
> 
> Of course, whether this actually makes sense for you in your
> situation depends on many factors.
> 
> 
> Dan
> 
> 
> 
> On Thu, Sep 12, 2013 at 5:44 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> Hello,
> 
> Our current handling of -fno-math-errno (and this -ffast-math) in
> Clang is broken on systems for which libm functions do actually set
> errno. This is because, when -fno-math-errno is in effect, libm
> functions like sqrt, sin, cos, etc. are marked as readnone. As a
> result, these calls can be reordered with respect to other calls
> that set errno, and can clobber errno before it can be read. For
> example:
> 
> int fd = open(...);
> if (fd == -1) {
> perror("oops");
> }
> double f = sqrt(a);
> 
> If we're on a system (like Linux, for example), where sqrt might set
> errno to EDOM when a is negative, we can have a problem if some
> optimization rearranges the code to something like this:
> 
> int fd = open(...);
> double f = sqrt(a);
> if (fd == -1) {
> perror("oops");
> }
> 
> if the open fails, and a is -2.0, then perror will print the wrong
> error string (thus confusing the user). This is not really a problem
> with the optimization because sqrt was marked as readnone. On the
> other hand, we don't want to tag sqrt and writing to some arbitrary
> external state variable, because this will prevent
> autovectorization, will prevent CSE from collecting duplicate calls
> to sqrt, and a host of other important optimizations.
> 
> To fix this problem, I think that we need to stop treating errno as
> some arbitrary external state, and model is explicitly. Functions
> need to be able carry two additional attributes:
> 
> 1. 'writes-only-errno' - An attribute to indicate that the function
> may set errno, and that is the only external state to which it might
> write. This is useful because getModRefInfo queries can return more
> accurate answers when comparing to pointers that we know cannot
> point to errno (such as alloca'd memory and functions) [is this
> allowed at all?].
> 
> 2. 'errno-ignored' - Set when -fno-math-errno is in effect,
> indicating that it is safe to assume that the user does not care
> about any value of errno set by this function. This will allow CSE
> and autovectorization to happen (by modifying those passes to
> specifically query this attribute).
> 
> With these new attributes, the functions are, on systems for which
> libm functions might set errno, not marked readnone or readonly.
> This will prevent unwanted reordering. Thoughts?
> 
> Thanks again,
> Hal
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On Fri, Sep 13, 2013 at 2:07 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
> >
> > Food for thought: If you have a codebase which can't use
> > -fno-math-errno, because it relies on errno values from math
> > functions, it may be a more effective long-term strategy to work on
> > modernizing your codebase, eliminating the dependencies on errno,
> > rather than going through the trouble of adding even more complexity
> > to compilers to keep errno support limping along.
> >
>
> Wouldn't that require 'modernizing' POSIX? ;) How else can you
get the
> error code from open() or any number of other functions

open is not a math function.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130913/67f88e9b/attachment.html>

----- Original Message -----
> 
> On Fri, Sep 13, 2013 at 2:07 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> 
> 
> 
> ----- Original Message -----
> > 
> > Food for thought: If you have a codebase which can't use
> > -fno-math-errno, because it relies on errno values from math
> > functions, it may be a more effective long-term strategy to work on
> > modernizing your codebase, eliminating the dependencies on errno,
> > rather than going through the trouble of adding even more
> > complexity
> > to compilers to keep errno support limping along.
> > 
> 
> Wouldn't that require 'modernizing' POSIX? ;) How else can you
get
> the error code from open() or any number of other functions
> 
> 
> open is not a math function.
> 
Sorry, I misread your initial statement... but this whole issue is not about
codes that need errno from math functions; that's supported just fine now.
The problem is that the math functions, whether you use the errno return or not,
may write to errno. And, because we currently mark these functions as readnone
when -fmath-errno=0, we might reorder these functions w.r.t. other functions
that do set errno, like open, and from which we care about errno's value.

 -Hal
> 
> Dan
> 
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory