[cxx-abi-dev] Guaranteed copy elision and tail padding

[Richard Smith]

On 21 July 2016 at 11:45, John McCall <rjmccall at apple.com> wrote:

> > On Jul 21, 2016, at 11:02 AM, Jason Merrill <jason at redhat.com> wrote:
> > P0135 seems to require that we elide the copy when using the result of
> > a function returning by value to initialize a base class subobject,
> > but the ABI doesn't currently require that such a function avoid
> > clobbering tail padding when initializing its return object.
> > Thoughts?
>
> This is not possible in general.  A function returning by value returns a
> complete
> object, i.e. one with its own virtual base subobjects.  We have no choice
> but to
> emit that to a temporary and move out of the non-virtual subobject.
>

That's a great point. At least for classes with virtual bases, we need to
go via a temporary object when initializing a base class with a prvalue.
I'll file a core issue for this.


> The next semantic question is whether it's compatible with NRVO, i.e.
> whether
> there are guarantees about the existence of padding on named local
> variables.
>
> Assuming that it's possible in some definable cases (and I think you could
> easily revise the standard to make it only apply to classes without
> v-bases),
> it seems abstractly reasonable.  Certainly it's generally preferable to
> avoid
> a high-level copy/move + destroy pair than to use a larger store at the end
> of very specific initializers.
>
> As an implementor, I think I'm most worried about how this + NRVO would
> mess up our existing peepholes that assume the existence of tail padding
> on certain complete objects.
>
> John.
> _______________________________________________
> cxx-abi-dev mailing list
> cxx-abi-dev at codesourcery.com
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20160721/baa5eb26/attachment.html>