Displaying 5 results from an estimated 5 matches for "n2454".
Did you mean:
2454
2020 Jan 07
3
Calling function from non-default floating-point environment
...ion of #pragma STDC FENV_ACCESS raises a problem: what to do if
a function is called inside a region where FP environment differs from the
default? If the function expects default FP mode it may work incorrectly in
such case.
The C2x standard draft (
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf) states (7.6p4):
Certain programming conventions support the intended model of use for the
dynamic floating-point environment:*)
— a function call does not alter its caller’s floating-point control modes,
clear its caller’s floating point status flags, nor depend on the state of
its caller’s f...
2020 Mar 03
5
Should rint and nearbyint be always constrained?
...>>> side effects by default there is no difference between llvm.rint and
>>> llvm.nearbyint. I wouldn’t have a problem with dropping llvm.rint
>>> completely.
>>
>>
>> The forthcoming C standard (
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf, 7.12.9.8)
>> defines new function, `roundeven`, which implements IEEE-754 operation
>> `roundToIntegralTiesToEven`. When corresponding intrinsic will be
>> implemented (I am working on such patch), llvm.rint and llvm.nearbyint will
>> identical to llvm.roundeven in defa...
2020 Mar 05
3
Should rint and nearbyint be always constrained?
+cfe-dev as the discussion is now biased toward C standard.
I'm not sure what problem you see here. In default mode, i.e.
> when there is no "#pragma STDC FENV_ACCESS on" in effect,
> then the compiler can always assume that the default rounding
> mode is in effect.
Well, if #pragma STDC FENV_ACCESS on is not in effect, that means
> that the user has promised that at
2020 Mar 03
2
Should rint and nearbyint be always constrained?
...e I see is that since we also assume FP operations have no
> side effects by default there is no difference between llvm.rint and
> llvm.nearbyint. I wouldn’t have a problem with dropping llvm.rint
> completely.
The forthcoming C standard (
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf, 7.12.9.8)
defines new function, `roundeven`, which implements IEEE-754 operation
`roundToIntegralTiesToEven`. When corresponding intrinsic will be
implemented (I am working on such patch), llvm.rint and llvm.nearbyint will
identical to llvm.roundeven in default environment and both can be drop...
2020 Mar 02
2
Should rint and nearbyint be always constrained?
Some clarification after getting feedback from Craig Topper….
It’s probably best to say in the documentation that the llvm.nearbyint and llvm.rint functions “assume the default rounding mode, roundToNearest”. This will allow the optimizer to transform them as if they were rounding to nearest without requiring backends to use an encoding that enforces roundToNearest as the rounding mode for these