[PATCH] D55897: Add constrained fptrunc and fpext intrinsics

Kevin P. Neal via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 25 09:24:45 PST 2019


kpn marked an inline comment as done.
kpn added inline comments.


================
Comment at: docs/LangRef.rst:14529
+      @llvm.experimental.constrained.fptrunc(<type> <value>,
+                                          metadata <exception behavior>)
+
----------------
cwabbott wrote:
> Hi,
> 
> I've been working on implementing a Vulkan extension which allows the user to specifiy different rounding modes for the AMDGPU backend. I'm not sure how this works in C/C++, but we're required to support floating-point truncation with non-standard rounding modes. Is there a reason the rounding mode isn't an argument here?
Going back and rereading D43515, I don't see an explicit reason given back then. And I can't find anything in the C99 or IEEE 754 standards, or in the LLVM documentation, that would mandate any particular rounding mode. So I'm open to adding a rounding mode argument to the constrained fptrunc.

Andrew? What do you think of making constrained fptrunc go back to taking a rounding mode argument? 

Having said that, the constrained FP intrinsics are to avoid optimizations that change program behavior taking traps into account. Is this the behavior you need for Vulcan?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55897/new/

https://reviews.llvm.org/D55897





More information about the llvm-commits mailing list