It looks like the intention here is to truncate a XLenVT -> i1, in
which case we should be emitting snez instead of sneq if I'm understanding
correctly.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Comment Actions
Hi, we are observing failures in the llvm testsuite (when compiling with -march=rv64gcv) and git bisect pointed here
Failed Tests (2): test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr53645-2.test test-suite :: SingleSource/Regression/C/gcc-c-torture/execute/GCC-C-execute-pr53645.test
can anyone else reproduce this issue too?
Comment Actions
I think SETEQ was correct before. We're checking the result of vfirst which can return a value between [-1, VL). We want to know specifically if bit 0 is set. There are 3 cases to consider. If bit 0 is set, the result of the vfirst will be 0. If bit 0 is not set but some other bit is, the result of the vfirst will be >0. The third case is that bit 0 isn't set and no other bits are set. In that case the vfirst will return -1.
The first case is the only case we should return 1. So we should be checking that the result of the vfirst is equal to 0, the original code before this patch.