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

[Stephen Canon via llvm-dev]

To be totally clear: this is true of *all* approaches to constant-folding functions that are not fully-specified.  Even if host is the targeted system, implementations change, bugs get fixed, etc.

– Steve

> On Apr 4, 2016, at 10:01 AM, Stephen Canon via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> MPFR suffers from the same problem as host library routines; the results don’t (in general) match what you get at runtime.
> 
> - Steve
> 
>> On Apr 4, 2016, at 9:49 AM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> 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 <mailto: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/ed52afee/attachment.html>