[PATCH] D50616: [Fixed Point Arithmetic] FixedPointCast

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Aug 13 12:02:06 PDT 2018


rjmccall added inline comments.


================
Comment at: lib/CodeGen/CGExprScalar.cpp:1016
+  if (DstScale > SrcScale) {
+    // Need to allocate space before shifting left
+    ResultWidth = SrcWidth + DstScale - SrcScale;
----------------
In IR, this isn't really "allocating" space.


================
Comment at: lib/CodeGen/CGExprScalar.cpp:1034
+  if (DstFPSema.isSaturated() &&
+      (CGF.getContext().getCorrespondingSaturatedType(SrcTy) != DstTy)) {
+    auto Mask = APInt::getBitsSetFrom(
----------------
Why is this condition based on the formal types exactly matching rather than something about the FP semantics being different?  Formal types can correspond to the same format, right?

We need to check for saturation if we're either (1) decreasing the magnitude of the highest usable bit or (2) going signed->unsigned, (2) we're going signed->unsigned, or (3) we're going unsigned->signed without increasing the number of integral bits.  And I'd expect the checks we have to do in each case to be different.


================
Comment at: lib/Sema/SemaExpr.cpp:5889
+    case Type::STK_MemberPointer:
+      llvm_unreachable("Unimplemented conversion from FixedPoint to type");
+    }
----------------
Is there something I'm missing that actually diagnoses the unimplemented cases here?  There's a lot of code that seems to assume that any two arithmetic types can be converted to each other, and we do prefer not to crash the compiler, especially on valid code.


Repository:
  rC Clang

https://reviews.llvm.org/D50616





More information about the cfe-commits mailing list