search for: flt_eval_method

...ssing from this list which matters for x87 and m68k fpu support and may matter for _Float16 implementations that fall back to _Float32 arithmetic. Yeah, we don't currently have any support for controlling that, at least in the x87 case. I think our current strategy is nothing more than setting FLT_EVAL_METHOD to reflect that we might not be using source precision for intermediate results. This is something we should consider adding. > the granularity of these knobs is also interesting (expression, code block, function or translation unit), iso c pragmas work on code block level. I'd have to de...

All: There will be a BoF talk at the EuroLLVM conference regarding Numerics (FMF and module flags which control fp behavior and optimization). Even if you are not going to be in attendance, please reply to this thread as we are collecting open issues and ideas for future direction in all layers of LLVM for which optimizations are controlled by numerics flags. Please read over the numerics blog

.... > I am not sure we have the same interpretation of what the FP_CONTRACT pragma does. Subclause 6.5 paragraph 8 of C11 implies (for example) that even where the FENV_ACCESS pragma is "on", folding a constant subexpression with an exactly representable result on an implementation where FLT_EVAL_METHOD is 0 is within the range of acceptable implementation-defined behaviour despite intermediate overflow under non-contracted evaluation. Which is to say that the current proposal reads as what needs to be done when FP_CONTRACT is "off" and FENV_ACCESS is "on". The note from Ulrich...

...nowing if the current proposals also take into > account the FP_CONTRACT pragma We should already do this (we turn relevant operations into the @llvm.fmuladd. when FP_CONTRACT is set to on during IR generation). > and the ability to implement options that imply a specific value for > the FLT_EVAL_METHOD macro. What do you mean by this?  -Hal > > Additionally, I am not aware of the IR being able to represent the > potentially deferred loss of precision that the C language semantics > provide; in particular, applying such semantics to the existing IR > would hit an issue that the l...

...pragmas are applied): no_honor_nans { on } no_honor_infinities { on } FLT_ROUNDS Should be set to -1 (indeterminable) if rounding_mode() is dynamic or 1 (tonearest) if rounding_mode is tonearest. There are values for other rounding modes, but clang offers no way to set those rounding modes. FLT_EVAL_METHOD Should be set to -1 if any of allow_reciprocal, allow_approximate_fns, or allow_reassociation is set. Should any other flags also make this -1? Otherwise, the setting is target-defined. math_errhandling The MATH_ERRNO bit will be set or cleared based on the setting of support_math_errno. Should...

...{ on } > > > > FLT_ROUNDS > > > > Should be set to -1 (indeterminable) if rounding_mode() is dynamic or 1 > (tonearest) if rounding_mode is tonearest. There are values for other rounding > modes, but clang offers no way to set those rounding modes. > > > > FLT_EVAL_METHOD > > > > Should be set to -1 if any of allow_reciprocal, allow_approximate_fns, or > allow_reassociation is set. Should any other flags also make this -1? Otherwise, > the setting is target-defined. > > > > math_errhandling > > > > The MATH_ERRNO bit will be...

...6.h (working copy) @@ -764,7 +764,13 @@ extern int x86_prefetch_sse; /* target machine storage layout */ +/* APPLE LOCAL begin LLVM */ +#ifdef ENABLE_LLVM +#define LONG_DOUBLE_TYPE_SIZE 64 +#else #define LONG_DOUBLE_TYPE_SIZE 80 +#endif +/* APPLE LOCAL end LLVM */ /* Set the value of FLT_EVAL_METHOD in float.h. When using only the FPU, assume that the fpcw is set to extended precision; when using Applied to gcc/gcc/config/i386/i386.h If that doesn't help, please send me a stack trace of the crash. To do this, pass -v to the failing GCC command line, then debug the cc1 invocatio...

Chris Lattner wrote: > Here's a new snapshot of the front-end: > http://nondot.org/sabre/2006-03-14-llvm-gcc-4.tar.gz > > This: > > 1. Fixes the inline asm problem you have above. > 2. Includes patches to make it better on Alpha's (thanks to patches by > Andrew Lenharth). > 3. Sync's it up with debug info changes in LLVM CVS (by Jim Laskey). > 4.

Hi Ulrich, I am interested in knowing if the current proposals also take into account the FP_CONTRACT pragma and the ability to implement options that imply a specific value for the FLT_EVAL_METHOD macro. Additionally, I am not aware of the IR being able to represent the potentially deferred loss of precision that the C language semantics provide; in particular, applying such semantics to the existing IR would hit an issue that the limits of such deferment would need an agreed representation...

>> Sorry for the delay, please try this tarball: >> http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gz > > There's some confusion with --enable-llvm configure parameter. I've built > LLVM to a separate build dir. The source is ~ghost/Work/llvm-cvs and build > dir is /space/p2/ghost/build/llvm-cvs ... > So, it seems like, at the same time: > > 1. buildir

Hello, at the recent EuroLLVM developer meeting in Bristol I held a BoF session on the topic "Towards implementing #pragma STDC FENV_ACCESS". I've also had a number of follow-on discussions both on-site in Bristol and online since. This post is intended as a summary of my current understanding set of requirements and implementation details covering the overall topic. I'm

...6_prefetch_sse; > > > /* target machine storage layout */ > > +/* APPLE LOCAL begin LLVM */ > +#ifdef ENABLE_LLVM > +#define LONG_DOUBLE_TYPE_SIZE 64 > +#else > #define LONG_DOUBLE_TYPE_SIZE 80 > +#endif > +/* APPLE LOCAL end LLVM */ > > /* Set the value of FLT_EVAL_METHOD in float.h. When using only the > FPU, assume that the fpcw is set to extended precision; when using > > > Applied to gcc/gcc/config/i386/i386.h > > If that doesn't help, please send me a stack trace of the crash. > To do this, pass -v to the failing GCC command lin...

Hello everyone. I'm not an expert neither in llvm nor in x86 nor in IEEE standard for floating point numbers, thus any of my following assumptions maybe wrong. If so, I will be grateful if you clarify me what's goes wrong. But if my guesses are correct we possibly have a bug in fp arithmetics on x86. I have the following ir: @g = constant i64 1 define i32 @main() { %gval = load

...pragmas are applied): no_honor_nans { on } no_honor_infinities { on } FLT_ROUNDS Should be set to -1 (indeterminable) if rounding_mode() is dynamic or 1 (tonearest) if rounding_mode is tonearest. There are values for other rounding modes, but clang offers no way to set those rounding modes. FLT_EVAL_METHOD Should be set to -1 if any of allow_reciprocal, allow_approximate_fns, or allow_reassociation is set. Should any other flags also make this -1? Otherwise, the setting is target-defined. math_errhandling The MATH_ERRNO bit will be set or cleared based on the setting of support_math_errno. Should...