Displaying 9 results from an estimated 9 matches for "counttrailingzero".
Did you mean:
counttrailingzeros
2016 Jul 21
2
FreeBSD user willing to try fix a unit test?
...fined(__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, i33minus2.getActiveBits());
EXPECT_EQ(1u, i33minus2.countTrailingZeros());
EXPECT_EQ(32u, i33minus2.countPopulation());
EXPECT_EQ(-2, i33minus2.getSExtValue());
EXPECT_EQ(((uint64_t)-2)&((1ull<<33) -1), i33minus2.getZExtValue());
}
#endif
Given that we are long past gcc 4.2, any chance someone with FreeBSD could check this now works and remove the X...
2011 Jun 21
2
[LLVMdev] Register class proliferation
...for getCommonSubClass() which could easily be fixed. I've never seen it show up on a Shark trace, though.
If we give each register class a bit vector of sub-classes, the currently linear isSubClass() / isSuperClass() would become constant time, and getCommonSubClass() could be made linear with CountTrailingZeros(A and B).
Yes, those bit vectors would require N^2 space, but the constant factor is 1 bit, so I don't care. I am not adding that many register classes.
/jakob
2016 Apr 14
2
Integer -> Floating point -> Integer cast optimizations
...t this up in IRC and was told to consult someone who knows more about floating point numbers; I propose an optimization as follows.
>
> Let's say we have an int x, and we cast it to a float and back. Floats have 8 exponent bits and 23 mantissa bits.
>
> If x matches the condition `countTrailingZeros(abs(x)) > (log2(abs(x)) - 23)`, then we can remove the float casts.
>
> So, if we can establish that abs(x) is <= 2**23, we can remove the casts. LLVM does not currently perform that optimization on this C code:
>
> int floatcast(int x) {
> if (abs(x) <= 16777216) { //...
2011 Jun 21
0
[LLVMdev] Register class proliferation
On Jun 21, 2011, at 8:51 AM, Jakob Stoklund Olesen wrote:
> In the past, I've seen some pushback on the list against adding more register classes. You can see it in the code as well, TargetLowering::getRegClassForInlineAsmConstraint() returns a vector of registers instead of a real register class.
>
> What is the reason we don't like adding register classes? Is it still a valid
2016 Apr 15
2
Integer -> Floating point -> Integer cast optimizations
...consult someone who knows more about floating point numbers; I propose an optimization as follows.
>>>
>>> Let's say we have an int x, and we cast it to a float and back. Floats have 8 exponent bits and 23 mantissa bits.
>>>
>>> If x matches the condition `countTrailingZeros(abs(x)) > (log2(abs(x)) - 23)`, then we can remove the float casts.
>>>
>>> So, if we can establish that abs(x) is <= 2**23, we can remove the casts. LLVM does not currently perform that optimization on this C code:
>>>
>>> int floatcast(int x) {
>>...
2011 Jun 21
2
[LLVMdev] Register class proliferation
In the past, I've seen some pushback on the list against adding more register classes. You can see it in the code as well, TargetLowering::getRegClassForInlineAsmConstraint() returns a vector of registers instead of a real register class.
What is the reason we don't like adding register classes? Is it still a valid reason?
The new register allocators, fast and greedy, don't care at
2011 Jun 22
0
[LLVMdev] Register class proliferation
...monSubClass() which could easily be fixed. I've never seen it show up on a Shark trace, though.
>
> If we give each register class a bit vector of sub-classes, the currently linear isSubClass() / isSuperClass() would become constant time, and getCommonSubClass() could be made linear with CountTrailingZeros(A and B).
>
> Yes, those bit vectors would require N^2 space, but the constant factor is 1 bit, so I don't care. I am not adding that many register classes.
We should make it clear that the performance problem is with register aliases, not classes. Register aliasing is a serious probl...
2009 Jan 20
0
[LLVMdev] cygwin build patch
On Jan 20, 2009, at 1:22 AM, Jay Foad wrote:
>>> I realise that the DataTypes.h.in part might be controversial. Also,
>>> there's probably a better place to put it, but I'm not sure where.
>>
>> I didn't apply this part. What problems does it cause to not have
>> this? Can we fix uses of max and min?
>
> I could try to fix this by changing
2009 Jan 20
4
[LLVMdev] cygwin build patch
>> I realise that the DataTypes.h.in part might be controversial. Also,
>> there's probably a better place to put it, but I'm not sure where.
>
> I didn't apply this part. What problems does it cause to not have
> this? Can we fix uses of max and min?
I get these errors in lib:
.../lib/Analysis/ValueTracking.cpp:162: error: no matching function
for call to