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

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. Note that the
non-transcendental functions are quite a different deal, especially
reasonable well behaving functions like log and exp.

Joerg

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160405/18a54b45/attachment.html>

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> 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>