[llvm-dev] llvm.rint specification

[Cameron McInally via llvm-dev]

On Wed, Nov 14, 2018 at 1:52 PM Zakharin, Vyacheslav P <
vyacheslav.p.zakharin at intel.com> wrote:

> Hi Cameron,
>
>
>
> Thank you for the comments, but I am confused even more now J
>
>
>
> > llvm.rint won't honor the FPEnv in all cases. It falls under the
> default FPEnv
>
> The default FPEnv section specifies round-to-nearest rounding mode.  In
> this case, how is it correct to map rint() user call to llvm.rint intrinsic
> call?
>

So the default FPEnv section *assumes* round-to-nearest. I think there's a
subtle difference there. The intrinsics are optimized assuming that the
FPEnv won't change. The user *can* change the FPEnv around intrinsic uses
in this mode. Although, it's not guaranteed that optimizations won't change
the intended behavior.

The constrained intrinsics offer (or I should say "will offer") more
guarantees about optimizations and FPEnv safety.

That all said, I don't think there are any guarantees that an explicit libm
call would honor the FPEnv either. The opaqueness of the libm call might
give a modicum of security when interacting with the FPEnv, but I'm not
aware of any hard guarantees.

Is there a particular llvm.rint test case that you're worried about? I'm
under the impression that if a target expands this intrinsic, then it will
fall back to the libm call. I also checked x86 and it produces VROUND with
an 0x4 immediate, which should emulate libm's results (or pretty close to
it). That is, of course, assuming that the optimizer didn't move the call
around functions that could change the FPEnv.


> If this is just a temporary inconsistency, and the long term solution is
> to map rint() user call to llvm.experimental.constrained.rint intrinsic
> call, I am OK with this.  If it is not, then I must be missing something.
>

I joined this project after the design was already laid down, so I don't
want to speak for everyone. But IMO, yes, we would merge both intrinsics in
the future. I do not see a clear path to optimizing the
llvm.experimental.constrained.xxx intrinsics, without a tremendous amount
of churn, under the current design.

I am sorry if this has been described somewhere in the RFC for the
> constrained FP intrinsics, which I haven’t read yet.
>

No apologies necessary. I didn't know about this until your email. ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181114/9e553f45/attachment.html>