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

[James Molloy via llvm-dev]

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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160404/9c80119e/attachment.html>