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

Craig Topper via llvm-commits llvm-commits at lists.llvm.org
Sun Mar 5 16:30:37 PST 2017


For more weird things, the APInt constructor from uint64_t writes 0 to VAL
first presumably to 0 the entire union which again assumes that's the
largest union member? Then overwrites it completely in the small case or
lets the slow case init overwrite the pointer part of it on 32-bit
architectures.

The copy constructor does something similar.

~Craig

On Sun, Mar 5, 2017 at 2:32 PM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Sun, Mar 5, 2017 at 8:29 AM Craig Topper via Phabricator <
> reviews at reviews.llvm.org> wrote:
>
>> craig.topper added a comment.
>>
>> 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.
>>
>
> If you like, might make the patch quicker/easier to review.
>
>
>>
>> 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?
>>
>
> Even the assignment operator sort of seems not quite right - but maybe I'm
> being overly cautious/incorrect here. (I'd expect it to need to memcpy the
> union itself (which would need a name)).
>
> Could also use the 'unified assignment operator' style - simplifying the
> copy/move assignment operator to rely on the copy/move ctors.
>
>
>>
>>
>> https://reviews.llvm.org/D30612
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170305/5c9ca70e/attachment.html>


More information about the llvm-commits mailing list