Displaying 3 results from an estimated 3 matches for "countleadingzeroes".
2016 Jul 21
2
FreeBSD user willing to try fix a unit test?
Hi all
In unittests/ADT/APIntTest.cpp I came across this test:
// XFAIL this test on FreeBSD where the system gcc-4.2.1 seems to miscompile it.
#if defined(__llvm__) || !defined(__FreeBSD__)
TEST(APIntTest, i33_Count) {
APInt i33minus2(33, static_cast<uint64_t>(-2), true);
EXPECT_EQ(0u, i33minus2.countLeadingZeros());
EXPECT_EQ(32u, i33minus2.countLeadingOnes());
EXPECT_EQ(33u,
2016 Mar 02
2
Why LLVM cannot optimize this?
Hi,
Yes SCEV is pretty limited on this aspect.
This kind of code can trigger LLVM to explode in time/memory: https://llvm.org/bugs/show_bug.cgi?id=18606 <https://llvm.org/bugs/show_bug.cgi?id=18606>
See also this llvm-dev thread: SCEV implementation and limitations, do we need "pow"? : http://lists.llvm.org/pipermail/llvm-dev/2014-February/070062.html
CC: Sanjoy who may have an
2013 Sep 04
4
PATCH: bugfixes for bitmath.h
More or less detailed explanation of this patch.
1. The first parameter of _BitScanReverse() and _BitScanReverse64() is a pointer to unsigned long (4-byte int). However _BitScanReverse64() is called with a pointer to FLAC__uint64 (8-byte int). IMHO it's a bug and this patch changes the type of idx variable inside FLAC__bitmath_ilog2_wide() from FLAC__uint64 to unsigned long.
The type of idx