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

Fri Mar 1 09:13:07 PST 2013

----- 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:48:50 AM
> Subject: Re: [llvm] r176292 - Brag about function call vectorization in the docs.
> 
> 
> On 01.03.2013, at 17:26, 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 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.
> 
> What exactly do you want to have documented? We won't ever vectorize
> a function setting errno like cos() without explicitly passing
> -ffast-math or -fno-math-errno to the compiler.

Okay, good. We may want to explicitly mention this on the vectorization page. While this is the behavior that I would expect, I think it may be non-obvious to many potential users.

 -Hal

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