James Molloy via llvm-dev
2016-Apr-04 18:30 UTC
[llvm-dev] RFC: Constant folding math functions for long double
Hi, If you're interested, include/bits/random.tcc:3312 (std::generate_canonical()). I wish I could just point people at libc++, but that's outside of my control. As for fixing the library, that horse bolted some time ago. Cheers, James On Mon, 4 Apr 2016 at 18:50 Stephen Canon <scanon at apple.com> wrote:> That sounds like a library issue that qualifies as “somewhat strange”. > Why does this require a log at all? > > – Steve > > On Apr 4, 2016, at 10:46 AM, James Molloy via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi Joerg, > > > IMO if constant folding of transcendental functions makes a significant > difference for your program, you likely are doing something strange > already. > > Alas it's not as simple as that. Currently, if you declare: > > std::uniform_real_distribution<float> x; > > LLVM emits two calls to logl() with constant arguments, a fdiv and a > fptoui. > > Libc++'s implementation is consumed and folded much more nicely by LLVM, > but at the moment anyone comparing LLVM and GCC will think that GCC is > around 40% better for some workloads. > > James > > On Mon, 4 Apr 2016 at 17:49 Reid Kleckner <rnk at google.com> wrote: > >> My feeling is that we shouldn't be relying on host long double routines. >> We're already skating on thin ice by relying on host double and float >> routines. This is a great way to make the compilation result vary depending >> on the host, which is something we try to avoid. >> >> An optional MPFR dependency would also be pretty painful. I expect it >> will frequently be missing and will not be exercised by most buildbots. >> >> On Mon, Apr 4, 2016 at 6:59 AM, James Molloy via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Hi, >>> >>> Clang is currently unable to constant fold calls to math.h functions >>> such as logl(), expl() etc. >>> >>> The problem is that APFloat doesn't have these functions, so Clang is >>> forced to rely on the host math library. Because long double isn't >>> portable, we only ever query the host math library for double or float >>> results. >>> >>> I can see three methods for allowing constant folding for types that are >>> larger than double, some more expensive than others: >>> >>> 1. Introduce a dependency on libMPFR, as GCC does. The dependency >>> could be hard or soft, with a fallback to the current behaviour if it >>> doesn't exist. >>> 2. Write the trancendental functions ourselves in APFloat (yuck!) >>> 3. If the long double format on the compiler host is the same as the >>> target, use the host library. >>> >>> (2) is the hardest. (3) is the easiest, but only works in a subset of >>> cases and I really don't like the idea of better output when compiling on >>> one platform compared to another (with equivalent targets). >>> >>> What do people think about (1)? Or is this completely out of the >>> question? >>> >>> Cheers, >>> >>> James >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> _______________________________________________ > 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/20160404/084836e7/attachment.html>
Chandler Carruth via llvm-dev
2016-Apr-04 18:41 UTC
[llvm-dev] RFC: Constant folding math functions for long double
My two cents: 1) While I'm sympathetic to Steve's point about this not always being desirable, the fact than *many* other compilers do this will ensure that code is written assuming it. I think we need to have support for this in order to have even remotely performance portable library code. 2) I strongly dislike an optional dependency on MPFR. We shouldn't have critical functionality tied to system libraries IMO. I understand that it is a *lot* of work, but I think we need to produce or get contributed a reasonable implementation of these routines under the LLVM license. As an added benefit, we might be able to (eventually) share the code for them with a runtime library that provides portable implementations for systems where hardware support is lacking. -Chandler On Mon, Apr 4, 2016 at 11:31 AM James Molloy via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi, > > If you're interested, include/bits/random.tcc:3312 > (std::generate_canonical()). I wish I could just point people at libc++, > but that's outside of my control. As for fixing the library, that horse > bolted some time ago. > > Cheers, > > James > > On Mon, 4 Apr 2016 at 18:50 Stephen Canon <scanon at apple.com> wrote: > >> That sounds like a library issue that qualifies as “somewhat strange”. >> Why does this require a log at all? >> >> – Steve >> >> On Apr 4, 2016, at 10:46 AM, James Molloy via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> Hi Joerg, >> >> > IMO if constant folding of transcendental functions makes a significant >> difference for your program, you likely are doing something strange >> already. >> >> Alas it's not as simple as that. Currently, if you declare: >> >> std::uniform_real_distribution<float> x; >> >> LLVM emits two calls to logl() with constant arguments, a fdiv and a >> fptoui. >> >> Libc++'s implementation is consumed and folded much more nicely by LLVM, >> but at the moment anyone comparing LLVM and GCC will think that GCC is >> around 40% better for some workloads. >> >> James >> >> On Mon, 4 Apr 2016 at 17:49 Reid Kleckner <rnk at google.com> wrote: >> >>> My feeling is that we shouldn't be relying on host long double routines. >>> We're already skating on thin ice by relying on host double and float >>> routines. This is a great way to make the compilation result vary depending >>> on the host, which is something we try to avoid. >>> >>> An optional MPFR dependency would also be pretty painful. I expect it >>> will frequently be missing and will not be exercised by most buildbots. >>> >>> On Mon, Apr 4, 2016 at 6:59 AM, James Molloy via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> Hi, >>>> >>>> Clang is currently unable to constant fold calls to math.h functions >>>> such as logl(), expl() etc. >>>> >>>> The problem is that APFloat doesn't have these functions, so Clang is >>>> forced to rely on the host math library. Because long double isn't >>>> portable, we only ever query the host math library for double or float >>>> results. >>>> >>>> I can see three methods for allowing constant folding for types that >>>> are larger than double, some more expensive than others: >>>> >>>> 1. Introduce a dependency on libMPFR, as GCC does. The dependency >>>> could be hard or soft, with a fallback to the current behaviour if it >>>> doesn't exist. >>>> 2. Write the trancendental functions ourselves in APFloat (yuck!) >>>> 3. If the long double format on the compiler host is the same as the >>>> target, use the host library. >>>> >>>> (2) is the hardest. (3) is the easiest, but only works in a subset of >>>> cases and I really don't like the idea of better output when compiling on >>>> one platform compared to another (with equivalent targets). >>>> >>>> What do people think about (1)? Or is this completely out of the >>>> question? >>>> >>>> Cheers, >>>> >>>> James >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> _______________________________________________ > 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/20160404/17438935/attachment-0001.html>
James Molloy via llvm-dev
2016-Apr-04 19:03 UTC
[llvm-dev] RFC: Constant folding math functions for long double
Hi Chandler, Your point of view makes sense. I'd support it strongly myself if I saw it happening... :( There are math libraries out there decently licensed that we could adapt - ARM has released our own math libraries for example. However adapting these to be arbitrary precision is certainly nontrivial and is something I'd be completely incapable of doing. My numerical analysis is not very hot and ULP means nothing to me :( James On Mon, 4 Apr 2016 at 19:41, Chandler Carruth <chandlerc at google.com> wrote:> My two cents: > > 1) While I'm sympathetic to Steve's point about this not always being > desirable, the fact than *many* other compilers do this will ensure that > code is written assuming it. I think we need to have support for this in > order to have even remotely performance portable library code. > > 2) I strongly dislike an optional dependency on MPFR. We shouldn't have > critical functionality tied to system libraries IMO. I understand that it > is a *lot* of work, but I think we need to produce or get contributed a > reasonable implementation of these routines under the LLVM license. As an > added benefit, we might be able to (eventually) share the code for them > with a runtime library that provides portable implementations for systems > where hardware support is lacking. > > -Chandler > > On Mon, Apr 4, 2016 at 11:31 AM James Molloy via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> If you're interested, include/bits/random.tcc:3312 >> (std::generate_canonical()). I wish I could just point people at libc++, >> but that's outside of my control. As for fixing the library, that horse >> bolted some time ago. >> >> Cheers, >> >> James >> >> On Mon, 4 Apr 2016 at 18:50 Stephen Canon <scanon at apple.com> wrote: >> >>> That sounds like a library issue that qualifies as “somewhat strange”. >>> Why does this require a log at all? >>> >>> – Steve >>> >>> On Apr 4, 2016, at 10:46 AM, James Molloy via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>> Hi Joerg, >>> >>> > IMO if constant folding of transcendental functions makes a >>> significant >>> difference for your program, you likely are doing something strange >>> already. >>> >>> Alas it's not as simple as that. Currently, if you declare: >>> >>> std::uniform_real_distribution<float> x; >>> >>> LLVM emits two calls to logl() with constant arguments, a fdiv and a >>> fptoui. >>> >>> Libc++'s implementation is consumed and folded much more nicely by LLVM, >>> but at the moment anyone comparing LLVM and GCC will think that GCC is >>> around 40% better for some workloads. >>> >>> James >>> >>> On Mon, 4 Apr 2016 at 17:49 Reid Kleckner <rnk at google.com> wrote: >>> >>>> My feeling is that we shouldn't be relying on host long double >>>> routines. We're already skating on thin ice by relying on host double and >>>> float routines. This is a great way to make the compilation result vary >>>> depending on the host, which is something we try to avoid. >>>> >>>> An optional MPFR dependency would also be pretty painful. I expect it >>>> will frequently be missing and will not be exercised by most buildbots. >>>> >>>> On Mon, Apr 4, 2016 at 6:59 AM, James Molloy via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>>> Hi, >>>>> >>>>> Clang is currently unable to constant fold calls to math.h functions >>>>> such as logl(), expl() etc. >>>>> >>>>> The problem is that APFloat doesn't have these functions, so Clang is >>>>> forced to rely on the host math library. Because long double isn't >>>>> portable, we only ever query the host math library for double or float >>>>> results. >>>>> >>>>> I can see three methods for allowing constant folding for types that >>>>> are larger than double, some more expensive than others: >>>>> >>>>> 1. Introduce a dependency on libMPFR, as GCC does. The dependency >>>>> could be hard or soft, with a fallback to the current behaviour if it >>>>> doesn't exist. >>>>> 2. Write the trancendental functions ourselves in APFloat (yuck!) >>>>> 3. If the long double format on the compiler host is the same as the >>>>> target, use the host library. >>>>> >>>>> (2) is the hardest. (3) is the easiest, but only works in a subset of >>>>> cases and I really don't like the idea of better output when compiling on >>>>> one platform compared to another (with equivalent targets). >>>>> >>>>> What do people think about (1)? Or is this completely out of the >>>>> question? >>>>> >>>>> Cheers, >>>>> >>>>> James >>>>> >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> llvm-dev at lists.llvm.org >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>> >>>>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >>> _______________________________________________ >> 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/20160404/7a0b8002/attachment.html>
Hal Finkel via llvm-dev
2016-Apr-04 20:45 UTC
[llvm-dev] RFC: Constant folding math functions for long double
----- Original Message -----> From: "Chandler Carruth via llvm-dev" <llvm-dev at lists.llvm.org> > To: "James Molloy" <james at jamesmolloy.co.uk>, "Stephen Canon" > <scanon at apple.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Monday, April 4, 2016 1:41:05 PM > Subject: Re: [llvm-dev] RFC: Constant folding math functions for long > double> My two cents:> 1) While I'm sympathetic to Steve's point about this not always being > desirable, the fact than *many* other compilers do this will ensure > that code is written assuming it. I think we need to have support > for this in order to have even remotely performance portable library > code.+1> 2) I strongly dislike an optional dependency on MPFR. We shouldn't > have critical functionality tied to system libraries IMO. I > understand that it is a *lot* of work, but I think we need to > produce or get contributed a reasonable implementation of these > routines under the LLVM license. As an added benefit, we might be > able to (eventually) share the code for them with a runtime library > that provides portable implementations for systems where hardware > support is lacking.+1 The prospect of having Clang compiled with MPFR available produce different code, even on otherwise identical base systems, than Clang compiled without it seems highly undesirable (especially since we might have only small numerical differences as observable effects). Plus, there are licensing considerations in environments where we need to statically link LLVM (in JITs and such) that I don't think we want to impose on downstream developers/distributors. However, the good news is that developing our own APFloat versions of these functions is relatively easy -- not easy in an absolute sense, but: 1) Unlike the libc implementations, we're not worried about raw performance on native types, 2) we can use large floats with a lot of extra precision easily, and 3) we don't need to use algorithms designed to be efficient for really-large bit counts (like MPFR does). In this regard, it might also be helpful to look at: https://github.com/JuliaLang/openlibm (which seems to be very-permissively licensed and has reference implementations for all of the relevant algorithms in C). -Hal> -Chandler> On Mon, Apr 4, 2016 at 11:31 AM James Molloy via llvm-dev < > llvm-dev at lists.llvm.org > wrote:> > Hi, >> > If you're interested, include/bits/random.tcc:3312 > > (std::generate_canonical()). I wish I could just point people at > > libc++, but that's outside of my control. As for fixing the > > library, > > that horse bolted some time ago. >> > Cheers, >> > James >> > On Mon, 4 Apr 2016 at 18:50 Stephen Canon < scanon at apple.com > > > wrote: >> > > That sounds like a library issue that qualifies as “somewhat > > > strange”. Why does this require a log at all? > > >> > > – Steve > > >> > > > On Apr 4, 2016, at 10:46 AM, James Molloy via llvm-dev < > > > > llvm-dev at lists.llvm.org > wrote: > > > > > >> > > > Hi Joerg, > > > > > >> > > > > IMO if constant folding of transcendental functions makes a > > > > > significant difference for your program, you likely are doing > > > > > something strange > > > > > > > > > > already. > > > > > >> > > > Alas it's not as simple as that. Currently, if you declare: > > > > > >> > > > std::uniform_real_distribution<float> x; > > > > > >> > > > LLVM emits two calls to logl() with constant arguments, a fdiv > > > > and > > > > a > > > > fptoui. > > > > > >> > > > Libc++'s implementation is consumed and folded much more nicely > > > > by > > > > LLVM, but at the moment anyone comparing LLVM and GCC will > > > > think > > > > that GCC is around 40% better for some workloads. > > > > > >> > > > James > > > > > >> > > > On Mon, 4 Apr 2016 at 17:49 Reid Kleckner < rnk at google.com > > > > > wrote: > > > > > >> > > > > My feeling is that we shouldn't be relying on host long > > > > > double > > > > > routines. We're already skating on thin ice by relying on > > > > > host > > > > > double and float routines. This is a great way to make the > > > > > compilation result vary depending on the host, which is > > > > > something > > > > > we > > > > > try to avoid. > > > > > > > > > >> > > > > An optional MPFR dependency would also be pretty painful. I > > > > > expect > > > > > it > > > > > will frequently be missing and will not be exercised by most > > > > > buildbots. > > > > > > > > > >> > > > > On Mon, Apr 4, 2016 at 6:59 AM, James Molloy via llvm-dev < > > > > > llvm-dev at lists.llvm.org > wrote: > > > > > > > > > >> > > > > > Hi, > > > > > > > > > > > > > > >> > > > > > Clang is currently unable to constant fold calls to math.h > > > > > > functions > > > > > > such as logl(), expl() etc. > > > > > > > > > > > > > > >> > > > > > The problem is that APFloat doesn't have these functions, > > > > > > so > > > > > > Clang > > > > > > is > > > > > > forced to rely on the host math library. Because long > > > > > > double > > > > > > isn't > > > > > > portable, we only ever query the host math library for > > > > > > double > > > > > > or > > > > > > float results. > > > > > > > > > > > > > > >> > > > > > I can see three methods for allowing constant folding for > > > > > > types > > > > > > that > > > > > > are larger than double, some more expensive than others: > > > > > > > > > > > > > > >> > > > > > 1. Introduce a dependency on libMPFR, as GCC does. The > > > > > > dependency > > > > > > could be hard or soft, with a fallback to the current > > > > > > behaviour > > > > > > if > > > > > > it doesn't exist. > > > > > > > > > > > > > > > > > > > > > 2. Write the trancendental functions ourselves in APFloat > > > > > > (yuck!) > > > > > > > > > > > > > > > > > > > > > 3. If the long double format on the compiler host is the > > > > > > same > > > > > > as > > > > > > the > > > > > > target, use the host library. > > > > > > > > > > > > > > >> > > > > > (2) is the hardest. (3) is the easiest, but only works in a > > > > > > subset > > > > > > of > > > > > > cases and I really don't like the idea of better output > > > > > > when > > > > > > compiling on one platform compared to another (with > > > > > > equivalent > > > > > > targets). > > > > > > > > > > > > > > >> > > > > > What do people think about (1)? Or is this completely out > > > > > > of > > > > > > the > > > > > > question? > > > > > > > > > > > > > > >> > > > > > Cheers, > > > > > > > > > > > > > > >> > > > > > James > > > > > > > > > > > > > > >> > > > > > _______________________________________________ > > > > > > > > > > > > > > > > > > > > > LLVM Developers mailing list > > > > > > > > > > > > > > > > > > > > > llvm-dev at lists.llvm.org > > > > > > > > > > > > > > > > > > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > > > > > > > > > >> > > > _______________________________________________ > > > > > > > > > > LLVM Developers mailing list > > > > > > > > > > llvm-dev at lists.llvm.org > > > > > > > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > >> > _______________________________________________ > > > LLVM Developers mailing list > > > llvm-dev at lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160404/87b3f051/attachment-0001.html>