search for: maytrap

...e can't use select even with constrained intrinsics, because the constrained intrinsics only tell the optimizer they can't be speculated. This is not a legal translation: %cond = fabs(c[i]) > epsilon %temp = select %cond, llvm.experimental.constrained.fdiv(b[i], c[i], tonearest, maytrap), 0 store a[i], %temp According to the IR, we've already speculated llvm.experimental.constrained.fdiv above the test. I believe the only way to safely do this with the current IR is via control flow and now we have to match complex control flow during isel. Who knows what other things...

...> 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 defer to someone more familiar with the front end to say how that is handled. > -ftrapping-math vs -ffp-exception-behaviour=maytrap is unclear. The "maytrap" setting is supposed to prevent the optimizer from introducing spurious exceptions (e.g. speculative execution) while still allowing it to optimize away potential exceptions (e.g. dce operations whose results are never used). > FLT_ROUNDS, FLT_EVAL_METHOD an...

...st} -f[no-]honor-infinities -f[no-]honor-nans -f[no-]associative-math -f[no-]reciprocal-math -f[no-]signed-zeros -f[no-]trapping-math -f[no-]rounding-math -fdenormal-fp-math={ieee, preservesign, positivezero} -fdenormal-fp-math-fp32={ieee, preservesign, positivezero} -ffp-exception-behavior={ignore,maytrap,strict} Each of these has a 1-to-1 correspondance to an FP semantic mode. (I think several of these should set "except_behavior" to "ignore".) -f[no-]finite-math-only Controls no_honor_nans and no_honor_infinities. -f[no-]unsafe-math-optimizations Turns no_signed_zero...

...floating-point operations. This is equivalent to "fpexcept.strict" in the constrained intrinsics review D53157. safe - Tells the compiler to disable speculation if there is a possibility that the speculation may cause a floating-point exception. This is equivalent to "fpexcept.maytrap" in the constrained intrinsics review D53157.

...> > -f[no-]reciprocal-math > > -f[no-]signed-zeros > > -f[no-]trapping-math > > -f[no-]rounding-math > > -fdenormal-fp-math={ieee, preservesign, positivezero} > > -fdenormal-fp-math-fp32={ieee, preservesign, positivezero} > > -ffp-exception-behavior={ignore,maytrap,strict} > > Each of these has a 1-to-1 correspondance to an FP semantic mode. > > (I think several of these should set "except_behavior" to "ignore".) > > -ftrapping-math vs -ffp-exception-behaviour=maytrap is unclear. > > (-ftrapping-math is weird...

Philip Reames <listmail at philipreames.com> writes: >> Masking has advantages even in the default non-trapping fp >> environment: It is not uncommon for fp hardware to be slow on >> denormal values. If you take the operation + select approach, >> spurious computation on denomals could occur, slowing down the >> program. > Why?  If you're backend has

...st} -f[no-]honor-infinities -f[no-]honor-nans -f[no-]associative-math -f[no-]reciprocal-math -f[no-]signed-zeros -f[no-]trapping-math -f[no-]rounding-math -fdenormal-fp-math={ieee, preservesign, positivezero} -fdenormal-fp-math-fp32={ieee, preservesign, positivezero} -ffp-exception-behavior={ignore,maytrap,strict} Each of these has a 1-to-1 correspondance to an FP semantic mode. (I think several of these should set "except_behavior" to "ignore".) -f[no-]finite-math-only Controls no_honor_nans and no_honor_infinities. -f[no-]unsafe-math-optimizations Turns no_signed_zero...