James Molloy via llvm-dev
2016-Apr-04 14:28 UTC
[llvm-dev] RFC: Constant folding math functions for long double
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/daf2a939/attachment.html>
Neil Henning via llvm-dev
2016-Apr-04 14:59 UTC
[llvm-dev] RFC: Constant folding math functions for long double
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 > <mailto: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/d5bba05a/attachment.html>
James Molloy via llvm-dev
2016-Apr-04 15:01 UTC
[llvm-dev] RFC: Constant folding math functions for long double
Hi Neil,> My problem with (3) is that you may get subtle precision differencesbetween 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>