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

[Neil Henning via llvm-dev]

Hey James,

Feel free to ping me off list if you are wanting to bounce ideas off of 
someone!

(For context - I wrote and maintain a high precision GPU math library at 
Codeplay as one of my many hats)

Cheers,
-Neil.

On 05/04/16 08:00, James Molloy via llvm-dev wrote:
> Hi,
>
> OK, writing an APFloat implementation of log and exp is a far more 
> tractable problem. Thanks for the feedback all!
>
> James
>
> On Tue, 5 Apr 2016 at 04:06 Chandler Carruth via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     On Mon, Apr 4, 2016 at 10:41 AM Joerg Sonnenberger via llvm-dev
>     <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>         On Mon, Apr 04, 2016 at 09:49:24AM -0700, Reid Kleckner via
>         llvm-dev wrote:
>         > An optional MPFR dependency would also be pretty painful. I
>         expect it will
>         > frequently be missing and will not be exercised by most
>         buildbots.
>
>         IMO if constant folding of transcendental functions makes a
>         significant
>         difference for your program, you likely are doing something
>         strange
>         already. I don't think it matters much for a lot of use cases,
>         so having
>         an optional dependency for this seems to be fine.
>
>
>     I think that if transcendental functions are sufficiently
>     unimportant, we shouldn't support them at all. We should have
>     consistent behavior rather than ending up with nearly impossible
>     to triage issues because one person's Clang used MPFR and the
>     other didn't.
>
>     While I think the optimizer should be able to constant fold
>     transcendentals as a matter of core competency, I don't have very
>     strong opinions about it for the reasons you cite -- I don't have
>     use cases.
>
>         Note that the
>         non-transcendental functions are quite a different deal,
>         especially
>         reasonable well behaving functions like log and exp.
>
>
>     Agreed, and I feel very strongly that we should support both log
>     and exp, and it has no business being optional.
>
>     But clearly the right way to do this is to start from the bottom
>     and work our way up. We should add the easiest ones first and
>     incrementally add support. I particularly like the suggestions
>     from Hal about how to make this a tractable engineering task.
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto: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/20160405/aa6071c8/attachment.html>