[PATCH] Have 'this'-returning constructors and destructors to take advantage of the new backend 'returned' attribute

John McCall rjmccall at apple.com
Thu May 2 21:09:04 PDT 2013


On May 2, 2013, at 7:55 PM, Stephen Lin <swlin at post.harvard.edu> wrote:
>> It would be reasonable to change ItaniumCXXABI's
>> BuildConstructorSignature to call HasThisReturn instead of relying
>> on overrides.
> 
> I was actually just going to have arrangeCXXConstructorDeclaration
> prepopulate ResTy based on HasThisReturn, since it's already
> prepopulating 'this'...
> 
> But (and I might be wrong, apologizes for my unfamiliarity with the
> code) it actually doesn't seem that easy to convert
> ConstructAttributeList to take a GlobalDecl with the appropriate
> constructor/destructor type, since ConstructAttributeList is called by
> EmitCall, which doesn't directly have the information either, and (I
> believe) the parameter needs to be on the call site in case the
> constructor is defined in a different TU?
> 
> Is there anything wrong with just checking the return type instead as
> I did in my revised patch? It's some coupling since it assumes the
> semantics of a constructor/destructor return value based on its type,
> but it seems to be a very justifiable assumption even for any future
> C++ ABI, and the assumption is documented.

Ah, I'm forgetting which functions are used from where.

I actually intentionally *don't* want this to be picked up in the same way
when constructing a call.  For example, virtual calls to destructors
cannot be marked with this attribute because none of these ABIs
put this-adjustment thunks in the v-table.  So it's quite important that
we only add this attribute on a call-site when directly calling a function.

That's also part of why I'm quite antsy about relying on the formal type
of the ctor/dtor.  The guarantee isn't necessarily there just because the
type is set up that way.

I'm not sure there's a compelling reason for EmitCall to get a Decl*
instead of a GlobalDecl.

John.



More information about the cfe-commits mailing list