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

[Benjamin Kramer]

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.

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