<div dir="ltr">Hi Sergey,<div><br></div><div>Since this is a very specific use case, where exceptions are trying to be triggered using strange constructs, might it not be simpler to introduce a simple builtin that musl could call instead?</div><div><br></div><div>Cheers,</div><div><br></div><div>James</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 October 2014 08:27, Sergey Dmitrouk <span dir="ltr"><<a href="mailto:sdmitrouk@accesssoftek.com" target="_blank">sdmitrouk@accesssoftek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Hal,<br>
<span class=""><br>
> And it is really (2) that is the larger problem: LLVM always might reorder the<br>
> FP operation you're trying to test and the function you're using to test the<br>
> FP exception state after the operation.<br>
<br>
</span>I didn't realize this can happen in general case, and it didn't occur in<br>
my use case.<br>
<span class=""><br>
> I'd like to understand exactly how you'd like to use this functionality.<br>
<br>
</span>I'm compiling musl-libc ([0]) with Clang. Its libm implementation (not<br>
sure how this is done in other libc implementation) relies on compiler to<br>
behave according to C standard (including Annex F.8). FP exceptions are<br>
generated with expressions such as "0.0/0.0", "1.0/0.0", "-1.0/0.0" or<br>
multiplications of huge/tiny values. Folding FP operations at compile<br>
time kills libm's ability to raise exceptions in quite a lot of cases.<br>
<br>
Thanks,<br>
Sergey<br>
<br>
0: <a href="http://www.musl-libc.org/" target="_blank">http://www.musl-libc.org/</a><br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Oct 09, 2014 at 08:09:59PM -0700, Hal Finkel wrote:<br>
> Hi Sergey,<br>
><br>
> Thanks for posting these. Just so we can better understand the boundary conditions here, can you please explain your use case? I ask because my understand is that there are really two parts to this problem:<br>
><br>
> 1. We sometimes "constant fold" away FP ops that might have set exception flags (overflow, underflow, etc.) -- Your patches address this.<br>
><br>
> 2. We have no way of expressing control dependencies on FP operations in LLVM on function calls that might manipulation the FP environment or read the exception state.<br>
><br>
> And it is really (2) that is the larger problem: LLVM always might reorder the FP operation you're trying to test and the function you're using to test the FP exception state after the operation. But this assumes that these function calls are also in the IR (perhaps they're not in your case), so I'd like to understand exactly how you'd like to use this functionality.<br>
><br>
> Thanks again,<br>
> Hal<br>
><br>
> ----- Original Message -----<br>
> > From: "Sergey Dmitrouk" <<a href="mailto:sdmitrouk@accesssoftek.com">sdmitrouk@accesssoftek.com</a>><br>
> > To: "llvm-commits" <<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>><br>
> > Sent: Friday, October 3, 2014 12:33:25 PM<br>
> > Subject: [PATCH] Flag to enable IEEE-754 friendly FP optimizations<br>
> ><br>
> > Hello,<br>
> ><br>
> > this is continuation of LLVM-dev's thread "More careful treatment of<br>
> > floating point exceptions". There wasn't much discussion there, so I<br>
> > just repeat updated version of the main part of text below.<br>
> ><br>
> > Currently, LLVM optimizes some floating point operations by replacing<br>
> > them with result evaluated at compile-time even if their execution at<br>
> > run-time would cause floating point exceptions. I'm trying to<br>
> > introduce<br>
> > a flag (off by default) that would disable such optimizations. This<br>
> > isn't trivial as related code is located in different parts of LLVM,<br>
> > so<br>
> > don't expect attached patches to be ready to be applied, they are<br>
> > rather<br>
> > something that works and require review from people that have much<br>
> > more<br>
> > experience with LLVM codebase than me.<br>
> ><br>
> > There are two sources of the flag (well three, if command-line option<br>
> > is<br>
> > counted): field of TargetOptions and function attribute. The later<br>
> > one<br>
> > is for InstCombine and similar passes, which do not have references<br>
> > to<br>
> > code generation option.<br>
> ><br>
> > Please find the attached patches. Is there a better way to implement<br>
> > patch<br>
> > number 0004? Would it make sense to mark IR instructions instead or<br>
> > maybe creating some special forms for them? The issue here is caused<br>
> > by an<br>
> > assumption that floating point operations are target independent,<br>
> > which<br>
> > doesn't hold if one wants an option to switch between optimized<br>
> > floating<br>
> > point operations and IEEE conformance. If there is another way to<br>
> > communicate state of the option to "target-independent" IR<br>
> > optimizations,<br>
> > which could replace adding additional argument to a bunch of<br>
> > functions, I<br>
> > would rather switched to it.<br>
> ><br>
> > Thanks,<br>
> > Sergey<br>
> ><br>
> > P.S. Also thinking about "PreserveFPExceptions" as an alternative<br>
> > name.<br>
> ><br>
> > _______________________________________________<br>
> > llvm-commits mailing list<br>
> > <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
> ><br>
><br>
> --<br>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>