<div dir="ltr">Hi Neil,<div><br></div><div>> <span style="line-height:1.5">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?</span></div><br><div>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.</div><div><br></div><div>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.</div><div><br></div><div>James</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 4 Apr 2016 at 15:59 Neil Henning <<a href="mailto:llvm@duskborn.com">llvm@duskborn.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Hey James,<br>
<br>
(2) is the best - although the most work (and I don't envy who would
have to do this!)<br>
<br>
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?<br>
<br>
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?)<br>
<br>
Cheers,<br>
-Neil.</div><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<div>On 04/04/16 15:28, James Molloy wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Neil,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Do you have an alternative solution or a preferred solution
of those I enumerated earlier?</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>James</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Mon, 4 Apr 2016 at 15:24 Neil Henning <<a href="mailto:llvm@duskborn.com" target="_blank"><a href="mailto:llvm@duskborn.com" target="_blank">llvm@duskborn.com</a></a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> Hey James,<br>
<br>
I really fundamentally dislike libMPFR.<br>
<br>
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?<br>
<br>
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.<br>
<br>
Cheers,<br>
-Neil.</div>
<div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<div>On 04/04/16 15:19, James Molloy wrote:<br>
</div>
<blockquote>Hi Neil,
<div><br>
</div>
<div>> Please not (1).<br>
</div>
<div><br>
</div>
<div>Could you please elaborate on your concern a bit
more?</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>James</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div></blockquote></div>