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

James Molloy via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 5 00:00:58 PDT 2016


OK, writing an APFloat implementation of log and exp is a far more
tractable problem. Thanks for the feedback all!


On Tue, 5 Apr 2016 at 04:06 Chandler Carruth via llvm-dev <
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> 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
> 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/3f59e1ba/attachment.html>

More information about the llvm-dev mailing list