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

[Lang Hames]

Ping.


On Mon, Jan 14, 2013 at 10:35 AM, Lang Hames <lhames at gmail.com> wrote:

> 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/20130124/eba0a621/attachment.html>