[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