search for: fp80

...ce_output for each system. > > I agree and understand, and we may need a tolerance in practice to deal with differences from denormal handling, etc. However, if Sebastian is seeing differences on the same system, we should understand why. Is he running on an ARM Darwin system, or an x86 using fp80 arithmetic, My dev machine is an x86_64-linux. This is where I ran all my reported results. How do I determine whether I am using fp80 arithmetic? Thanks, Sebastian

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

...es. I was emphasizing that rounding modes aren't part of the API. >> - Digits represented simply as a 32-bit or 64-bit integer. > > Isn’t this the same as the significand of an IEEE float? If you go with 64-bit, it sounds like you’re defining something very close to Intel’s FP80. Yup. The `uint64_t` version is similar to a non-conforming and slow FP80 that's always in denormal mode, but the *same* non-conforming on every platform.

I'm currently working on stripping usage of `UnsignedFloat` out of `-block-freq`. Before I finish... I propose adding a soft-float class to llvm/Support/ or llvm/Analysis/. - Portable (unlike hard-floats). - Well-defined for all platforms and safe to use in code. - Easy to use and reason about (unlike `APFloat`). - Uses operators. - No special numbers. - Every

Adrian Prantl via llvm-dev wrote on Mon, 02 Nov 2015: > Looking at the code in clang CGDebugInfo just passes through the > width of the type as it is described by the TypeInfo, which in turn > is defined by the Target. At the moment I do not understand why an > x86_fp80 is reported to be 128 bits wide. The x86-64 and Darwin/i386 ABI define the size of the 80 bits extended type in memory as 16 bytes. In all other i386 ABIs, it's defined as 12 bytes. Delphi and, for compatibility reasons, the Free Pascal Compiler use 10 bytes (although FPC also has a &quo...

...ing that rounding modes aren't part of the API. >> >>>> - Digits represented simply as a 32-bit or 64-bit integer. >>> Isn’t this the same as the significand of an IEEE float? If you go with 64-bit, it sounds like you’re defining something very close to Intel’s FP80. >> Yup. The `uint64_t` version is similar to a non-conforming and slow FP80 >> that's always in denormal mode, but the *same* non-conforming on every >> platform. >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev...

On 12 October 2016 at 14:26, Sebastian Pop <sebpop.llvm at gmail.com> wrote: > Correct me if I misunderstood: you would be ok changing the > reference output to exactly match the output of "-O0 -ffp-contract=off". No, that's not at all what I said. Matching identical outputs to FP tests makes no sense because there's *always* an error bar. The output of O0, O1, O2,

Hi Neil, I admit that at this point I haven't considered the implications of the license MPFR is under, and at the moment I'm sticking my head in the sand until and unless we want to go down this path. My expectation is that we would use their exposed API - so we'd #include <mpfr.h> and use functions from there, linking against -lmpfr and -lgmp. I admit that this option would