[LLVMdev] ConstantFoldBinaryFP and cross compilation

[Chandler Carruth]

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/20130428/e5dfeedc/attachment.html>