[llvm-dev] RFC: Constant folding math functions for long double

[Chandler Carruth via llvm-dev]

My two cents:

1) While I'm sympathetic to Steve's point about this not always being
desirable, the fact than *many* other compilers do this will ensure that
code is written assuming it. I think we need to have support for this in
order to have even remotely performance portable library code.

2) I strongly dislike an optional dependency on MPFR. We shouldn't have
critical functionality tied to system libraries IMO. I understand that it
is a *lot* of work, but I think we need to produce or get contributed a
reasonable implementation of these routines under the LLVM license. As an
added benefit, we might be able to (eventually) share the code for them
with a runtime library that provides portable implementations for systems
where hardware support is lacking.

-Chandler

On Mon, Apr 4, 2016 at 11:31 AM James Molloy via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> If you're interested, include/bits/random.tcc:3312
> (std::generate_canonical()). I wish I could just point people at libc++,
> but that's outside of my control. As for fixing the library, that horse
> bolted some time ago.
>
> Cheers,
>
> James
>
> On Mon, 4 Apr 2016 at 18:50 Stephen Canon <scanon at apple.com> wrote:
>
>> That sounds like a library issue that qualifies as “somewhat strange”.
>> Why does this require a log at all?
>>
>> – Steve
>>
>> On Apr 4, 2016, at 10:46 AM, James Molloy via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hi Joerg,
>>
>> > IMO if constant folding of transcendental functions makes a significant
>> difference for your program, you likely are doing something strange
>> already.
>>
>> Alas it's not as simple as that. Currently, if you declare:
>>
>> std::uniform_real_distribution<float> x;
>>
>> LLVM emits two calls to logl() with constant arguments, a fdiv and a
>> fptoui.
>>
>> Libc++'s implementation is consumed and folded much more nicely by LLVM,
>> but at the moment anyone comparing LLVM and GCC will think that GCC is
>> around 40% better for some workloads.
>>
>> James
>>
>> On Mon, 4 Apr 2016 at 17:49 Reid Kleckner <rnk at google.com> wrote:
>>
>>> My feeling is that we shouldn't be relying on host long double routines.
>>> We're already skating on thin ice by relying on host double and float
>>> routines. This is a great way to make the compilation result vary depending
>>> on the host, which is something we try to avoid.
>>>
>>> An optional MPFR dependency would also be pretty painful. I expect it
>>> will frequently be missing and will not be exercised by most buildbots.
>>>
>>> On Mon, Apr 4, 2016 at 6:59 AM, James Molloy via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> Clang is currently unable to constant fold calls to math.h functions
>>>> such as logl(), expl() etc.
>>>>
>>>> The problem is that APFloat doesn't have these functions, so Clang is
>>>> forced to rely on the host math library. Because long double isn't
>>>> portable, we only ever query the host math library for double or float
>>>> results.
>>>>
>>>> I can see three methods for allowing constant folding for types that
>>>> are larger than double, some more expensive than others:
>>>>
>>>>   1. Introduce a dependency on libMPFR, as GCC does. The dependency
>>>> could be hard or soft, with a fallback to the current behaviour if it
>>>> doesn't exist.
>>>>   2. Write the trancendental functions ourselves in APFloat (yuck!)
>>>>   3. If the long double format on the compiler host is the same as the
>>>> target, use the host library.
>>>>
>>>> (2) is the hardest. (3) is the easiest, but only works in a subset of
>>>> cases and I really don't like the idea of better output when compiling on
>>>> one platform compared to another (with equivalent targets).
>>>>
>>>> What do people think about (1)? Or is this completely out of the
>>>> question?
>>>>
>>>> Cheers,
>>>>
>>>> James
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160404/17438935/attachment-0001.html>