[cfe-commits] [PATCH] Smarter implicit copy-construction/copy-assignment.

[Lang Hames]

I think this applies equally to default move operators, I just hadn't done
enough homework to be sure yet.

- Lang.


On Fri, Jan 11, 2013 at 7:20 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> On Fri, Jan 11, 2013 at 7:05 PM, Lang Hames <lhames at gmail.com> wrote:
>
>> At present, if a class contains any Non-POD members we perform
>> element-wise copies for each field when generating the implicit
>> copy-constructor and implicit copy-assignment operator (with an
>> optimization for array members).
>>
>> This patch changes this behavior - adjacent POD members will be memcpy'd,
>> with Non-POD members output as usual.
>>
>> This is an initial implementation that I'd like to get in tree. Obvious
>> deficiencies are:
>>
>> It punts entirely when LangOpts.getGC != None.
>> It doesn't handle inner classes/unions.
>> It doesn't attach any TBAA info, even when all members are the same type.
>> It isn't particularly smart about when it falls back on element-wise
>> copies (at the moment it emits a memcpy any time it finds more than one POD
>> field).
>>
>> These should all be easy to test and remedy once the code's in tree
>> though.
>>
>> Does anybody see any problems with this?
>> Style comments?
>>
>> Feedback much appreciated.
>>
>
> This generally seems reasonable to me, but I've not looked at the patch in
> detail. Any reason not to apply this to move assignment operators too?
>
> Do you handle bitfields? See r151963 for an example of that.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130114/3af2e5bc/attachment.html>