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

[Neil Henning via llvm-dev]

Hey James,

(2) is the best - although the most work (and I don't envy who would 
have to do this!)

My problem with (3) is that you may get subtle precision differences 
between the constant-folded value calculated on host x86, to the library 
used on, for example, an ARM device. Maybe this isn't enough of an issue 
for most peoples purposes though?

I'd argue that if the size of long double format on the compiler host is 
greater than or equal to the target is ok too though (if we accept a 
differing of precision, why not allow a platform that has 80bit long 
double produce more precise values?)

Cheers,
-Neil.

On 04/04/16 15:28, James Molloy wrote:
> Hi Neil,
>
> I admit that at this point I haven't considered the implications of 
> the license MPFR is under, and at the moment I'm sticking my head in 
> the sand until and unless we want to go down this path.
>
> My expectation is that we would use their exposed API - so we'd 
> #include <mpfr.h> and use functions from there, linking against -lmpfr 
> and -lgmp. I admit that this option would indeed add another dimension 
> to the testing matrix.
>
> Do you have an alternative solution or a preferred solution of those I 
> enumerated earlier?
>
> Cheers,
>
> James
>
> On Mon, 4 Apr 2016 at 15:24 Neil Henning <llvm at duskborn.com 
> <mailto:llvm at duskborn.com>> wrote:
>
>     Hey James,
>
>     I really fundamentally dislike libMPFR.
>
>     License of the codebase aside, would a dependency be on the built
>     .so, or would it be that we'd want to pull in the code and build that?
>
>     My worry if we do bring it in even as a soft dependency is how is
>     this figured out - is it a case that CMake will, if it finds the
>     .so on the system, use and link against it? I worry that we are
>     introducing another matrix of potential failures if the lib is
>     present or not.
>
>     Cheers,
>     -Neil.
>
>
>     On 04/04/16 15:19, James Molloy wrote:
>
>         Hi Neil,
>
>         > Please not (1).
>
>         Could you please elaborate on your concern a bit more?
>
>         Cheers,
>
>         James
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160404/d5bba05a/attachment.html>