llvm dev - Apr 2016 - RFC: Constant folding math functions for long double

Hi Neil,
> Please not (1).
Could you please elaborate on your concern a bit more?

Cheers,

James

On Mon, 4 Apr 2016 at 15:18 Neil Henning via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Please not (1).
>
> Cheers,
> -Neil.
>
>
> On 04/04/16 14:59, James Molloy via llvm-dev 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 listllvm-dev at
lists.llvm.orghttp://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/7dbde9ca/attachment.html>

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/10eac7d2/attachment.html>

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> 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/daf2a939/attachment.html>