Displaying 4 results from an estimated 4 matches for "roundtonearest".
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 operations. On modern x86 targets we can encode it either way, but it seems more consistent to continue usi...
2020 Mar 03
2
Should rint and nearbyint be always constrained?
...t and the other does not. If we could
deliberately assign this property to a particular call, we could eventually
merge constrained and non-constrained intrinsics.
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 operations.
Optimizer could make the same optimization with constrained nearbyint and
rint...
2020 Mar 03
5
Should rint and nearbyint be always constrained?
...gt; deliberately assign this property to a particular call, we could eventually
>> merge constrained and non-constrained intrinsics.
>>
>> 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 operations.
>>
>>
>> Optimizer could make the same...
2020 Mar 02
2
Should rint and nearbyint be always constrained?
>
> I'm not sure why this is an issue. Yes, these two intrinsics depend
> on the current rounding mode according to the C standard, and yes,
> LLVM in default mode assumes that the current rounding mode is the
> default rounding mode. But the same holds true for many other
> intrinsics and even the arithmetic IR operations like add.
Any other intrinsic, like `floor`,