thr3ads.net - llvm dev - [LLVMdev] ConstantFoldBinaryFP and cross compilation [Apr 2013]

If this information is useful, please help other people find it:
Share via:

Dan Gohman

2013-Apr-26 21:04 UTC

[LLVMdev] ConstantFoldBinaryFP and cross compilation

Hi Sergei,

The degree to which LLVM actually makes any guarantees about IEEE
arithmetic precision is ambiguous. LangRef, for one, doesn't even mention
it (it mentions formats, but nothing else). The de-facto way of
interpreting holes in LangRef is to consider how the IR is used by clang
and follow the path up into the C and/or C++ standards and then work from
there. C describes a binding to IEC 60559, but it is optional, and clang
doesn't opt in. C++ doesn't even have the option. So from an official
perspective, it's not clear that you have any basis to complain ;-).

I mention all this not to dismiss your concern, but to put it in context.
Right or wrong, much of the C/C++ software world is not that keenly
concerned in these matters. This includes LLVM in some respects. The
folding of floating-point library routines which you point out in LLVM is
one example of this.

One idea for addressing this would be to teach LLVM's TargetLibraryInfo to
carry information about how precise the target's library functions are.
Then, you could either implement soft-float functions within LLVM itself
for the affected library functions, or you could disable folding for those
functions which are not precise enough on the host (in non-fast-math mode)

Another idea for addressing this would be to convince the LLVM community
that LLVM shouldn't constant-fold floating-point library functions at all
(in non-fast-math mode). I think you could make a reasonable argument for
this. There are ways to do this without loosing much optimization -- such
expressions are still constant after all, so they can be hoisted out of any
loop at all. They could even be hoisted out to main if you want. It's also
worth noting that this problem predates the implementation of fast-math
mode in LLVM's optimizer. Now that fast-math mode is available, it may be
easier to convince people to make the non-fast-math mode more conservative.
I don't know that everyone will accept this, but it's worth considering.

Dan

On Fri, Apr 26, 2013 at 12:44 PM, Sergei Larin <slarin at
codeaurora.org>wrote:
> Dan, and anyone else interested… ****
>
> ** **
>
>   I am not sure if this has been discussed before, but I do have a case
> when the following logic fails to work:****
>
> ** **
>
> lib/Analysis/ConstantFolding.cpp****
>
> ** **
>
> static Constant *ConstantFoldBinaryFP(double (*NativeFP)(double, double),*
> ***
>
>                                       double V, double W, Type *Ty) {****
>
>   sys::llvm_fenv_clearexcept();****
>
>   V = NativeFP(V, W);****
>
>   if (sys::llvm_fenv_testexcept()) {****
>
>     sys::llvm_fenv_clearexcept();****
>
>     return 0;****
>
>   }****
>
> ** **
>
> ….****
>
> ** **
>
> This fragment seems to assumes that host and target behave in exact the
> same way in regard to FP exception handling. In some way I understand it,
> but… On some cross compilation platforms this might not be always true. In
> case of Hexagon for example our FP math handling is apparently more precise
> then “stock” one on x86 host.  Specific (but not the best) example would be
> computing sqrtf(1.000001). Result is 1 + FE_INEXACT set. My current linux
> x86 host fails the inexact part… resulting in wrong code emitted.****
>
> ** **
>
>   Once again, my question is not about this specific example, but rather
> about the assumption of identical behavior of completely different systems.
> What if my target’s “objective” is to exceed IEEE precision? …and I happen
> to have a set of tests to verify that I do J****
>
> ** **
>
> Thank you for any comment.****
>
> ** **
>
> Sergei****
>
> ** **
>
> ** **
>
> ---****
>
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation****
>
> ** **
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130426/8192f702/attachment.html>

Sergei Larin

2013-Apr-26 22:07 UTC

head link

[LLVMdev] ConstantFoldBinaryFP and cross compilation

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 there J Is there anyone else that
would be concerned about this problem in any of it potential forms?

 

Sergei

 

---

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

 

From: Dan Gohman [mailto:dan433584 at gmail.com] 
Sent: Friday, April 26, 2013 4:04 PM
To: Sergei Larin
Cc: llvmdev at cs.uiuc.edu
Subject: Re: ConstantFoldBinaryFP and cross compilation

 

Hi Sergei,

 

The degree to which LLVM actually makes any guarantees about IEEE arithmetic
precision is ambiguous. LangRef, for one, doesn't even mention it (it
mentions formats, but nothing else). The de-facto way of interpreting holes
in LangRef is to consider how the IR is used by clang and follow the path up
into the C and/or C++ standards and then work from there. C describes a
binding to IEC 60559, but it is optional, and clang doesn't opt in. C++
doesn't even have the option. So from an official perspective, it's not
clear that you have any basis to complain ;-).

 

I mention all this not to dismiss your concern, but to put it in context.
Right or wrong, much of the C/C++ software world is not that keenly
concerned in these matters. This includes LLVM in some respects. The folding
of floating-point library routines which you point out in LLVM is one
example of this.

 

One idea for addressing this would be to teach LLVM's TargetLibraryInfo to
carry information about how precise the target's library functions are.
Then, you could either implement soft-float functions within LLVM itself for
the affected library functions, or you could disable folding for those
functions which are not precise enough on the host (in non-fast-math mode)

 

Another idea for addressing this would be to convince the LLVM community
that LLVM shouldn't constant-fold floating-point library functions at all
(in non-fast-math mode). I think you could make a reasonable argument for
this. There are ways to do this without loosing much optimization -- such
expressions are still constant after all, so they can be hoisted out of any
loop at all. They could even be hoisted out to main if you want. It's also
worth noting that this problem predates the implementation of fast-math mode
in LLVM's optimizer. Now that fast-math mode is available, it may be easier
to convince people to make the non-fast-math mode more conservative. I don't
know that everyone will accept this, but it's worth considering.

 

Dan

 

On Fri, Apr 26, 2013 at 12:44 PM, Sergei Larin <slarin at codeaurora.org>
wrote:

Dan, and anyone else interested. 

 

  I am not sure if this has been discussed before, but I do have a case when
the following logic fails to work:

 

lib/Analysis/ConstantFolding.cpp

 

static Constant *ConstantFoldBinaryFP(double (*NativeFP)(double, double),

                                      double V, double W, Type *Ty) {

  sys::llvm_fenv_clearexcept();

  V = NativeFP(V, W);

  if (sys::llvm_fenv_testexcept()) {

    sys::llvm_fenv_clearexcept();

    return 0;

  }

 

..

 

This fragment seems to assumes that host and target behave in exact the same
way in regard to FP exception handling. In some way I understand it, but. On
some cross compilation platforms this might not be always true. In case of
Hexagon for example our FP math handling is apparently more precise then
"stock" one on x86 host.  Specific (but not the best) example would be
computing sqrtf(1.000001). Result is 1 + FE_INEXACT set. My current linux
x86 host fails the inexact part. resulting in wrong code emitted.

 

  Once again, my question is not about this specific example, but rather
about the assumption of identical behavior of completely different systems.
What if my target's "objective" is to exceed IEEE precision? .and
I happen
to have a set of tests to verify that I do J

 

Thank you for any comment.

 

Sergei

 

 

---

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

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130426/3955686e/attachment.html>

Owen Anderson

2013-Apr-26 23:20 UTC

head link

[LLVMdev] ConstantFoldBinaryFP and cross compilation

On Apr 26, 2013, at 3:07 PM, Sergei Larin <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 there J Is 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.

--Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130426/9fcc2c7c/attachment.html>

Maybe Matching Threads

Search for more possibly parallel threads

llvm dev - Apr 2013 - [LLVMdev] ConstantFoldBinaryFP and cross compilation

[LLVMdev] ConstantFoldBinaryFP and cross compilation

[LLVMdev] ConstantFoldBinaryFP and cross compilation

[LLVMdev] ConstantFoldBinaryFP and cross compilation

Maybe Matching Threads