Displaying 6 results from an estimated 6 matches for "roundeven".
2020 Mar 03
5
Should rint and nearbyint be always constrained?
>
> One concern with replacing llvm.rint and llvm.nearbyint with
> llvm.roundeven makes it difficult to turn back into a libcall if the
> backend doesn't have an instruction for it. You can't just call the
> roundeven library function since that wouldn't exist in older libm
> implementations. So ideally you would know which function was originally
> used...
2020 Mar 03
2
Should rint and nearbyint be always constrained?
...ations 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 dropped.
We'll end up with a funny situation, th...
2020 Mar 05
3
Should rint and nearbyint be always constrained?
...*always* have the default FP environment.
>
This is a strong statement (no pragma == default mode), we need to confirm
it with proper references to the standard. If it is true and the code:
float qqq(float x) {
return nearbyint(x);
}
is really equivalent to:
float qqq(float x) {
return roundeven(x);
}
(in absence of 'pragma STD FENV_ACCESS), it is a fact that would be
surprise for many user.
Thanks,
--Serge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200306/49ead284/attachment.html>
2020 Mar 02
2
Should rint and nearbyint be always constrained?
...ounding 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`, `round` etc has meaning at default rounding mode. But use of `rint` or `nearbyint` in default FP environment is strange, `roundeven` can be used instead. We could use more general intrinsics in all cases, as the special case of default environment is not of practical interest.
There is another reason for special handling. Set of intrinsics includes things like `x86_sse_cvtss2si`. It is unlikely that all of them eventually get...
2020 Mar 02
2
Should rint and nearbyint be always constrained?
...e 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`, `round` etc has meaning at default
rounding mode. But use of `rint` or `nearbyint` in default FP environment
is strange, `roundeven` can be used instead. We could use more general
intrinsics in all cases, as the special case of default environment is not
of practical interest.
There is another reason for special handling. Set of intrinsics includes
things like `x86_sse_cvtss2si`. It is unlikely that all of them eventually
get...
2020 Mar 02
2
Should rint and nearbyint be always constrained?
Hi everyone,
According to the current design an intrinsic call that depends on current
floating point environment (for example, rounding mode) or change it (for
example by raising FP exceptions) is represented by constrained intrinsics.
The latter have attached metadata that provide info about current FP
environment and have attribute `IntrInaccessibleMemOnly` that helps keeping
order of