This is an archive of the discontinued LLVM Phabricator instance.

[APInt] Add rvalue reference support to and, or, xor operations to allow their memory allocation to be reused when possible
ClosedPublic

Authored by craig.topper on Mar 4 2017, 5:29 PM.

Details

Summary

This extends an earlier change that did similar for add and sub operations.

With this first patch we lose the fastpath for the single word case as operator&= and friends don't support it. This can be added there if we think that's important.

I had to change some functions in the APInt class since the operator overloads were moved out of the class and can't be used inside the class now. The getBitsSet change collides with another outstanding patch to implement it with setBits. But I didn't want to make this patch dependent on that series.

I've also removed the Or, And, Xor functions which were rarely or never used. I already commited two changes to remove the only uses of Or that existed.

Diff Detail

Repository
rL LLVM

Event Timeline

craig.topper created this revision.Mar 4 2017, 5:29 PM
dblaikie edited edge metadata.Mar 5 2017, 7:58 AM

Are the cleanup changes (removing unused operations, etc) tied to the main change here, or could they be done separately?

Also, it looks like the main change could be tested by using getRawData to demonstrate that the moves rather than copies happened, maybe?

(that said, the move ctor looks questionable - it copies a possibly inactive member of a union & relies on that to copy the other member of the union)

Removing the And, Or, Xor functions could be removed separately.

The change to getBitsSet and intersects were necessary because of the operator functions being moved out of line. But they could be done as a pre-patch.

I hadn't looked at the move constructor. I was basing this on r276470 and assuming it was ok. Should I change it to use memcpy like the move assignment operator?

Add unit tests. Rebase for the removal of And/Or/Xor methods in r296993.

dblaikie accepted this revision.Mar 6 2017, 4:11 PM

Looks reasonable - I would (vaguely/generally - haven't thought about it very hard) wonder if the test cases could be simpler. I'd expect only one constant, maybe - (b1100 - or any other 4 bit sequence with 2 x 1s and 2 x 0s, to test the usual combination of ones and zeros on each side in each operation?). & hardcode the expected result with a literal instead of another APInt? Not sure. Anyway - if that seems like the tidiest/simplest testing for it, that's OK.

This revision is now accepted and ready to land.Mar 6 2017, 4:11 PM
This revision was automatically updated to reflect the committed changes.