<div dir="ltr">My two cents:<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Chandler</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 4, 2016 at 11:31 AM James Molloy via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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.</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 18:50 Stephen Canon <<a href="mailto:scanon@apple.com" target="_blank">scanon@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>That sounds like a library issue that qualifies as “somewhat strange”. Why does this require a log at all?</div><div><br></div><div>– Steve</div></div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Apr 4, 2016, at 10:46 AM, James Molloy via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr">Hi Joerg,<div><br></div><div>> <span style="line-height:1.5">IMO if constant folding of transcendental functions makes a significant</span></div>difference for your program, you likely are doing something strange<br>already.<div><br></div><div>Alas it's not as simple as that. Currently, if you declare:</div><div><br></div><div>std::uniform_real_distribution<float> x;</div><div><br></div><div>LLVM emits two calls to logl() with constant arguments, a fdiv and a fptoui.</div><div><br></div><div>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.</div><div><br></div><div>James</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 4 Apr 2016 at 17:49 Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>An optional MPFR dependency would also be pretty painful. I expect it will frequently be missing and will not be exercised by most buildbots.</div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 4, 2016 at 6:59 AM, James Molloy via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="color:rgb(33,33,33);font-size:13px;line-height:19.5px">Hi,</span><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px"><br></div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px">Clang is currently unable to constant fold calls to math.h functions such as logl(), expl() etc.</div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px"><br></div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px">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.</div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px"><br></div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px">I can see three methods for allowing constant folding for types that are larger than double, some more expensive than others:</div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px"><br></div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px"> 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.</div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px"> 2. Write the trancendental functions ourselves in APFloat (yuck!)</div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px"> 3. If the long double format on the compiler host is the same as the target, use the host library.</div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px"><br></div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px">(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).</div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px"><br></div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px">What do people think about (1)? Or is this completely out of the question?</div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px"><br></div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px">Cheers,</div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px"><br></div><div style="color:rgb(33,33,33);font-size:13px;line-height:19.5px">James</div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div></div></blockquote></div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br></div></blockquote></div><br></div></blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>