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

[Benjamin Kramer]

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.

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

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