[PATCH] D106409: [PowerPC] Truncate results for out of range values for vec_cts,vec_ctf

Nemanja Ivanovic via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Sep 30 03:06:48 PDT 2021


nemanjai requested changes to this revision.
nemanjai added a comment.
This revision now requires changes to proceed.

I may be wrong, but I really think this is incorrect. Please do some functional (execution) testing on this. Also, please re-title this from "truncate results" to something like "truncate exponent parameter" or similar since you are not truncating the result but the parameter.



================
Comment at: clang/lib/Headers/altivec.h:3178
+      : (__builtin_vsx_xvcvuxdsp((vector unsigned long long)(__a)) *           \
+         (vector float)(vector unsigned)((0x7f - (__b)) << 23 & 0x1F)),        \
+        vector signed long long                                                \
----------------
Hmm... aren't you truncating the wrong thing here (and for all the other shifted ones? Shouldn't it be something like:
```
(vector float)(vector unsigned)((0x7f - ((__b) & 0x1F)) << 23)),
```


================
Comment at: clang/test/CodeGen/builtins-ppc-xlcompat.c:25
 // CHECK-NEXT:    [[TMP1:%.*]] = call <4 x float> @llvm.ppc.vsx.xvcvsxdsp(<2 x i64> [[TMP0]])
-// CHECK-NEXT:    fmul <4 x float> [[TMP1]], <float 6.250000e-02, float 6.250000e-02, float 6.250000e-02, float 6.250000e-02>
+// CHECK-NEXT:    fmul <4 x float> [[TMP1]], zeroinitializer 
 
----------------
Notice that all the `fmul`'s multiply by zero. This really doesn't seem right - and is likely due to shifting left and then truncating (i.e. you shift a value left by 23/52 bits, then you bitwise-and it with 0x1F - all you're going to get are zeros).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106409



More information about the cfe-commits mailing list