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

[James Molloy via llvm-dev]

Hi Neil,

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

Sure. My suggestion would be that we would refuse to constant fold values
when run on x86 targetting ARM for example, because ARM uses fp128 and x86
uses fp80. So what I suggest wouldn't be a codegen fault, it was just
optimize less in some cases.

I personally prefer (1), because not only is (2) a lot of work, it's a lot
of work that has a large scope for error.

James

On Mon, 4 Apr 2016 at 15:59 Neil Henning <llvm at duskborn.com> wrote:

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