[llvm] r176292 - Brag about function call vectorization in the docs.

[Hal Finkel]

----- Original Message -----
> From: "Benjamin Kramer" <benny.kra at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-commits at cs.uiuc.edu for LLVM" <llvm-commits at cs.uiuc.edu>
> Sent: Friday, March 1, 2013 10:01:26 AM
> Subject: Re: [llvm] r176292 - Brag about function call vectorization in the docs.
> 
> 
> On 01.03.2013, at 15:42, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> > ----- Original Message -----
> >> From: "Benjamin Kramer" <benny.kra at gmail.com>
> >> To: "Hal Finkel" <hfinkel at anl.gov>
> >> Cc: "llvm-commits at cs.uiuc.edu for LLVM" <llvm-commits at cs.uiuc.edu>
> >> Sent: Friday, March 1, 2013 2:16:09 AM
> >> Subject: Re: [llvm] r176292 - Brag about function call
> >> vectorization in the docs.
> >> 
> >> 
> >> On 01.03.2013, at 02:59, Hal Finkel <hfinkel at anl.gov> wrote:
> >> 
> >>> ----- Original Message -----
> >>>> From: "Benjamin Kramer" <benny.kra at googlemail.com>
> >>>> To: llvm-commits at cs.uiuc.edu
> >>>> Sent: Thursday, February 28, 2013 1:33:46 PM
> >>>> Subject: [llvm] r176292 - Brag about function call vectorization
> >>>> in the docs.
> >>>> 
> >>>> Author: d0k
> >>>> Date: Thu Feb 28 13:33:46 2013
> >>>> New Revision: 176292
> >>>> 
> >>>> URL: http://llvm.org/viewvc/llvm-project?rev=176292&view=rev
> >>>> Log:
> >>>> Brag about function call vectorization in the docs.
> >>>> 
> >>>> Modified:
> >>>>   llvm/trunk/docs/Vectorizers.rst
> >>>> 
> >>>> Modified: llvm/trunk/docs/Vectorizers.rst
> >>>> URL:
> >>>> http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Vectorizers.rst?rev=176292&r1=176291&r2=176292&view=diff
> >>>> ==============================================================================
> >>>> --- llvm/trunk/docs/Vectorizers.rst (original)
> >>>> +++ llvm/trunk/docs/Vectorizers.rst Thu Feb 28 13:33:46 2013
> >>>> @@ -245,6 +245,17 @@ See the table below for a list of these
> >>>> |     |     | fmuladd |
> >>>> +-----+-----+---------+
> >>>> 
> >>>> +The loop vectorizer knows about special instructions on the
> >>>> target
> >>>> and will
> >>>> +vectorize a loop containing a function call that maps to the
> >>>> instructions. For
> >>>> +example, the loop below will be vectorized on Intel x86 if the
> >>>> SSE4.1 roundps
> >>>> +instruction is available.
> >>>> +
> >>>> +.. code-block:: c++
> >>>> +
> >>>> +  void foo(float *f) {
> >>>> +    for (int i = 0; i != 1024; ++i)
> >>>> +      f[i] = floorf(f[i]);
> >>>> +  }
> >>> 
> >>> Do some of these only happen in fast-math mode? floorf is a nice
> >>> example because it will never set errno (according to the Linux
> >>> man page), and so is always safe. Nevertheless, for functions
> >>> that
> >>> set errno I assume we only do this in fast-math mode and we
> >>> should
> >>> say so (unless, of course, I'm wrong about that -- but in that
> >>> case, we might have a correctness problem).
> >> 
> >> We do this always. I audited all the libm function definitions in
> >> clang a while ago. Most of them set errno unless -fno-math-errno
> >> is
> >> specified (which is the default on BSDs).
> > 
> > FWIW, the gcc man page only mentions this as an issue on Darwin.
> > FreeBSD, etc. are the same way? I thought that Darwin was POSIX
> > certified, so is there an alternate environment that does set
> > errno as required?
> 
> There's a math_errhandling thing that specifies how errno and
> exceptions are handled on the system, if that's set right a system
> can be perfectly POSIX-compliant without ever setting errno on math
> functions.
> 
> -fno-math-errno is the default on all BSD-derivatives I'm aware of,
> including Darwin.

Interesting, thanks! I did not know about math_errhandling. The glibc man page says, "The  math_errhandling  identifier specified by C99 and POSIX.1-2001 is not supported by glibc."

Regardless, on systems that do set errno we can have a problem. If nothing else, we should at least document the current behavior? I'd rather do the correct thing on those systems so that there are no surprises.

> 
> > 
> >> The rounding functions
> >> like floorf are specified to set EDOM in POSIX afaik, but there is
> >> no way that could occur with our floating point types, so we mark
> >> it
> >> as not setting errno.
> > 
> > Right.
> > 
> > My issue is that cos(), for example, sets errno if you give it
> > pos/neg infty, and so without fast-math, you can't really safely
> > vectorize this (on POSIX-compliant systems anyway) if errno might
> > be checked afterward.
> > 
> >> 
> >> One thing we could do with -ffast-math is vectorizing sqrt(). I
> >> avoided that for now because the llvm.sqrt intrinsic has undefined
> >> behavior for negative numbers.
> > 
> > Yes; and the library call raises a floating-point exception so I
> > think we'd need some other explicit permission (metadata) to do
> > this.
> 
> Yeah, this one is tricky. I'm wondering what the rationale for making
> llvm.sqrt different from libm sqrt was.

To avoid this issue ;)

Thanks again,
Hal

> 
> - Ben
> 
> >>> On that thought, we might want some kind of analysis that can
> >>> determine if errno from some math function is unused so that we
> >>> can optimize regardless of the conformance mode when possible.
> >> 
> >> That's tricky though, errno is always a global variable but the
> >> way
> >> it's accessed varies from operating system to operating system.
> > 
> > I know, this is why I've not yet done this myself ;) -- We'd
> > probably need some kind of errno-recognition framework. Thinking
> > about it, it might make more sense for clang to recognize errno
> > access and tag it somehow.
> > 
> > Thanks again,
> > Hal
> > 
> >> 
> >> - Ben
> >>> 
> >>> Thanks again,
> >>> Hal
> >>> 
> >>>> 
> >>>> Partial unrolling during vectorization
> >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>>> 
> >>>> 
> >>>> _______________________________________________
> >>>> llvm-commits mailing list
> >>>> llvm-commits at cs.uiuc.edu
> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >>>> 
> >> 
> >> 
> 
>