[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 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?

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

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