[LLVMdev] [RFC] Identifying access to errno

Sat Nov 23 20:32:50 PST 2013

On Sat, Nov 23, 2013 at 4:50 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "David Majnemer" <david.majnemer at gmail.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: "Renato Golin" <renato.golin at linaro.org>, "LLVM" <
> llvmdev at cs.uiuc.edu>
> > Sent: Saturday, November 23, 2013 2:37:52 PM
> > Subject: Re: [LLVMdev] [RFC] Identifying access to errno
> >
> >
> > Oh, and I forgot a third "_doserrno" for which no amount of
> > documentation lends itself to a consistent description of its
> > behavior.
>
> Are all of these things possibly set by cos(double) and friends?
>

Math functions are special! :)

In error cases, they call a function call _matherr.  This function will
typically set only errno.  However, programs which link dynamically against
the MSVCRT are permitted to replace the function with whatever they want
(this is documented behavior!); their _matherr might forward it's arguments
to "fire_the_missiles".

>
>  -Hal
>
> >
> >
> >
> > On Sat, Nov 23, 2013 at 12:28 PM, David Majnemer <
> > david.majnemer at gmail.com > wrote:
> >
> >
> >
> >
> >
> >
> >
> > On Sat, Nov 23, 2013 at 9:59 AM, Hal Finkel < hfinkel at anl.gov >
> > wrote:
> >
> >
> >
> > ----- Original Message -----
> > > From: "Renato Golin" < renato.golin at linaro.org >
> > > To: "Hal Finkel" < hfinkel at anl.gov >
> > > Cc: "LLVM" < llvmdev at cs.uiuc.edu >
> > > Sent: Saturday, November 23, 2013 10:53:09 AM
> > > Subject: Re: [LLVMdev] [RFC] Identifying access to errno
> > >
> > >
> > >
> > >
> > > On 23 November 2013 14:14, Hal Finkel < hfinkel at anl.gov > wrote:
> > >
> > >
> > > On some systems (Linux/glibc, for example), some libm math
> > > functions
> > > (like cos(double)) might set errno. It is important that we model
> > > this, in general, to prevent miscompilation (we would not, for
> > > example, want to reorder a call to cos in between a call to open
> > > and
> > > a call to perror). However, almost no code in the wild checks errno
> > > after calls to libm math functions, and this errno-setting behavior
> > > prevents vectorization and other useful loop optimizations, CSE,
> > > etc. Also, currently, the scalar llvm.<libm function> intrinsics
> > > are
> > > subtly broken on systems where the underlying libm functions may
> > > set
> > > errno, because the intrinsics are readonly, and may be implemented
> > > by calls to the libm function (which might set errno), exposing us
> > > to reordering problems (as in the example above).
> > >
> > >
> > >
> > > Hi Hal,
> > >
> > >
> > > I'm confused. On one hand you're proposing us to stop reordering
> > > libm
> > > calls because they might set errno (I agree with this), but on the
> > > other hand you're saying that nobody cares and that prevents
> > > optimizations (not sure I agree with this).
> > >
> >
> > What I'm saying is that very few people actually check errno after
> > libm calls, and so we're often preventing vectorization for no good
> > reason. However, obviously we still need to prove that no errno
> > access is occurring if we want to vectorize (unfortunately, our
> > ability to do this may be limited outside of an LTO context -- but
> > under fast-math or with some pragma, etc. we may be able to change
> > the default assumptions). In short, I'm proposing that we both:
> >
> > 1. Be more strict to prevent unwanted reorderings (by actually
> > modeling that these functions may *write* to errno).
> >
> > 2. Improve our modeling of errno so that we can ignore said writes
> > (safely) when we know that value of errno is unused. A setting like
> > -fno-math-errno should not "remove" the modeling of these writes,
> > just declare our disinterest in the resulting value.
> >
> > But, what I'm trying to establish here is: how can we recognize
> > possible errno access so that explicitly modeling the writes to
> > errno does not unduly pessimize the surrounding code.
> >
> >
> > >
> > >
> > >
> > >
> > > 1. Assume that all unknown external functions might read/write
> > > errno
> > >
> > > 2. Assume that all i32 pointers might point to errno (although we
> > > might be able to do better by somehow leveraging TBAA for "int"?)
> > >
> > >
> > >
> > > Something like "MayBeErr", "IsErr", "IsntErr".
> >
> > On what?
> >
> >
> > >
> > >
> > >
> > >
> > >
> > > Does anyone see any problems with making stronger (type-based)
> > > assumptions re: errno (and, thus, on what things may alias with
> > > calls to errno-setting-libm functions)?
> > >
> > >
> > > I don't, but I'm trying to think of a way to disable it if we know
> > > it's "ok". Maybe -unsafe-math or something similar could disable
> > > this pass, because it is expensive and will impact generated code.
> > >
> >
> > We already run IPO/FunctionAttrs, and if we're conservative about
> > escape, it would not add any additional expense. (Ff we do top-down
> > propagation for static functions (or more-generally for LTO), then
> > that could add overhead).
> >
> >
> > >
> > >
> > >
> > >
> > > What if, for globals, we insisted that the global be named "errno"?
> > >
> > >
> > >
> > > I wouldn't be surprised if there was a system where the golbal
> > > error
> > > is not errno. Windows maybe?
> >
> > Okay. We should check.
> >
> >
> >
> > A Windows program can have two different global error numbers: Win32
> > and C-Runtime flavor.
> >
> >
> > The Win32 flavor is exposed via GetLastError/SetLastError[Ex]
> > The CRT flavor (errno) is, currently, exposed via a macro that
> > expands to (*_errno())
> >
> >
> >
> >
> > Thanks again,
> > Hal
> >
> > >
> > >
> > > --renato
> >
> >
> >
> > --
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131123/6950ac08/attachment.html>