similar to: [LLVMdev] [RFC] Add a simple soft-float class

> On 2014 Jun 17, at 21:59, Owen Anderson <resistor at mac.com> wrote: > > Hi Duncan, > > Some of these don’t make a lot of sense: Sorry -- I think I was assuming too much knowledge about what I committed as part of the BlockFrequencyInfo rewrite. What's committed there is a class called UnsignedFloat that wraps the following with a bunch of API: template

+1 I strongly question the wisdom of trying to invent our own floating point representation. IEEE 754 is, honestly, pretty damn well designed. Unless we all go spend a few years studying numerical analysis, we’re not going to design something here that is better, and are likely to get caught in numerical traps that using IEEE floating point would have protected us from. That said, I’m

On Tue, Jun 17, 2014 at 10:11 PM, Rafael Avila de Espindola < rafael.espindola at gmail.com> wrote: > If we require the host to have sse2 or other IEEE 754 conformant > implementation, would it be possible to use hardware float? > I don't think that IEEE 754 actually guarantees bit-exact results in all cases. -- Sean Silva > > Sent from my iPhone > > > On

On Jun 18, 2014, at 1:20 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > I'm certainly not suggesting this would be better in general than IEEE 754. > > But I think it's suitable for the sorts of places we currently use > hard-floats. I guess you (and Philip) are saying there are dragons here? Numerical analysis is hard. Every numerics expert I have

On Jun 18, 2014, at 8:38 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> >> On 2014 Jun 18, at 13:29, Owen Anderson <resistor at mac.com> wrote: >> >> Numerical analysis is hard. Every numerics expert I have ever worked with considers trying to re-invent floating point a cardinal sin of numerical analysis. Just don’t do it. You will miss

This patch supplies software IEEE floating point support. The comment from the patch reproduced below says all there is to say. This patch contains the prior "cleanup" patch; please don't apply that one. Please let me know of any bugs. It is tested reasonably well, but until I put together random tests it's hard to have 100% confidence. Neil. /* A self-contained host- and

Hi All, APFloat::fusedMultiplyAdd currently computes the wrong signed zero when small negative results are truncated back to zero in standard precision. The following snippet handles the signedness in fusedMultiplyAdd: /* If two numbers add (exactly) to zero, IEEE 754 decrees it is a positive zero unless rounding to minus infinity, except that adding two like-signed zeroes gives that

On 12 October 2016 at 15:05, Hal Finkel <hfinkel at anl.gov> wrote: > This is something we need to understand. No, there's not always an error bar. With FMA formation and without non-IEEE-compliant optimizations (i.e. fast-math), the optimized answer should be identical to the non-optimized answer. What about architectures that this is never respected, like Darwin? In the general

On Wed, Oct 12, 2016 at 10:28 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Renato Golin" <renato.golin at linaro.org> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "Sebastian Paul Pop" <s.pop at samsung.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Matthias

Hi Mehdi, Thanks for the feedback. I think the comment is fine - the problem is just that the original conditional didn't exactly match it. With the addition of the underflow check I believe the condition now matches the comment: The sign is only tweaked if the result of the addition is exactly zero, rather than a small result that truncates to zero. CC'ing llvm-commits, where this email

Ok, I had forgotten about sNaNs. Doesn't the same caveat apply to 0-sNaN then though or does that not signal? Does that mean we need a separate way to handle negate in the IR? Funnily enough, historically I believe we were using the multiplication by -1.0 because it was a more reliable negation that 0-x (from 3.0 until 3.3 at least). Is there a good reason why multiplication by NaN should kill

In r187314, APFloat multiplication by with NaNs was made to always yield a positive NaN. I am wondering whether that was the correct decision. It is of course true that the result of a multiplication is undefined in IEEE, however, we were using multiplication by -1.0 to implement IEEE negate, which is defined to preserve the sign bit. r210428 made 0-NaN have IEEE negate behavior, which is good

Hi Carter, I would strongly advise you against this direction. I’m aware of two directions that existing languages go in defining min/max operations: - IEEE 754, C, Fortran, Matlab, OpenCL, and HLSL all define it not to propagate NaNs - C++ (std::min/std::max) and OpenGL define it in the trinary operator manner: (a < b) ? a : b What you’re proposing does not match any existing languages

Neil Booth wrote: > Talin wrote:- > >> Well, I may be using it wrong. But looking at APFloat.h, I see four >> functions that purport to convert to integer: >> >> opStatus convertToInteger(integerPart *, unsigned int, bool, >> roundingMode) const; >> opStatus convertFromSignExtendedInteger(const integerPart *, >>

Hi, after upgrading to 2.1 I noticed that the format for floating point numbers in .ll files apparently changed. I now get errors like "llvm-as: var.ll:48,0: Floating point constant invalid for type" for such code: "@gmFloat = constant float 0.3". I checked with llvm-gcc and it now generates code for the hexadecimal floating point representation. The documentation at

On Wed, 29 Aug 2018 at 07:51, Cameron McInally via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The current thinking is that FNEG(X) and FSUB(-0.0, X) are not the same operation when X is a NaN or 0. Do you mean denormals (when flushed) rather than 0 there? AFAIK it's OK for 0 itself. > So, the xforms in question should only be valid under Fast-Math conditions. We could

On Oct 2, 2007, at 8:15 AM, Jan Rehders wrote: > Hi, > > after upgrading to 2.1 I noticed that the format for floating point > numbers in .ll files apparently changed. I now get errors like > > "llvm-as: var.ll:48,0: Floating point constant invalid for type" > > for such code: > > "@gmFloat = constant float 0.3". > > I checked with llvm-gcc

Hi, I've been playing around with the APFloat class lately and I came across behavior I was not expecting based on reading the implementation comments and I'm wondering if it's a bug or intentional. The behavior concerns converting an APFloat to a string and back again. In the implementation of ``APFloat::toString(...)`` you can specify ``FormatPrecision`` as 0. The method comments

This is a problem with all floating point folding, not just with these operations. What Matt is proposing is consistent with how we fold other libm intrinsics. —Owen > On Aug 18, 2014, at 1:22 AM, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > > Wouldn’t it be better to use the target’s implementation (if there is one)

Ok. That you for clarifying the point for me. I was primed for a regression because this behavior changed over llvm versions and was causing my tests to fail ;). I'm now doing bitcasting to int, xoring with the signbit and bitcasting back. On Thu, Aug 7, 2014 at 2:59 AM, Owen Anderson <resistor at mac.com> wrote: > Subtraction is also not a correct implementation of negation, for