[LLVMdev] ConstantFoldBinaryFP and cross compilation

[Sergei Larin]

So what is the verdict here? In my original question the host has a _bug_ in the implementation of fetestexcept() . Why it should affect the correctness of the code I produce?

 

Sergei

 

---

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chandler Carruth
Sent: Saturday, April 27, 2013 6:18 PM
To: Nick Lewycky
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] ConstantFoldBinaryFP and cross compilation

 

On Sat, Apr 27, 2013 at 7:26 PM, Nick Lewycky <nicholas at mxc.ca> wrote:

On 04/26/2013 04:20 PM, Owen Anderson wrote:


On Apr 26, 2013, at 3:07 PM, Sergei Larin <slarin at codeaurora.org

<mailto:slarin at codeaurora.org>> wrote:

Dan,
Thank you for the quick and throughout reply. First paragraph pretty
much sums it up. Unless there is more will to guaranty (or provide
under flag) stricter version of IEEE adherence, I doubt much can be done.

So all of you with picky customers out thereJIs there anyone else that


would be concerned about this problem in any of it potential forms?


I have the opposite problem. I have customers who call libm functions
with constants (or their LLVM intrinsic equivalents) are get very angry
if they don't get constant folded, and they're not picky at all about
the precision.


I just want LLVM to behave the same on whatever platform it's run on. People already accept that depending on iteration order is a bug, but it's been harder to get people to accept that llvm needs bit-exact floating point constant folding, especially given the implementation difficulty.

 

I'll give a huge +1 to this.

 

I think that long-term LLVM should, out of the box, support strictly correct (according to IEEE) floating point folding outside of fast-math, and should provide aggressive as hell folding inside of fast-math.

 

As Owen points out rightly, it would be important to provide flags to enable just the amount of folding that users have today and expect to keep, preferably as some rational subset of fast math.

 

However, I don't think either aggressive folding in fast-math or conservative behavior by default is nearly as important as what Nick pointed out: we should not under any circumstances expose the output of the optimizer to the whims of the host's FP. Even if we can write code to get deterministic results out of the host's FP unit (maybe, but hard and a huge maintenance burden), and even if the host's FP unit actually gives us deterministic results (questionable on some older chips), I most certainly don't want to assume that the host *compiler* will actually handle LLVM's host FP code correctly, especially given the current quality of LLVM's own optimizer for such code! =/ We should insulate ourselves from such concerns completely.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130429/67406db0/attachment.html>