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

[Stephen Lin]

Hi John, Manman,

This patch converts the implementation of 'this'-returning
constructors and destructors (in ARM and MS C++ ABIs) to use the new
'returned' attribute.

It does so by adding a new flag to FunctionType::ExtInfo and other
associated classes which indicates that a function returns its first
argument; only a single bit is used currently since the only use cases
for this attribute are for the first parameter, but the API is
designed to theoretically allow the the attribute on any parameter if
needed later by increasing the number of reserved flag bits for the
field.

Chris suggested allowing this attribute to be placed on library
functions which return 'this', which presumably would be done with a
front-end function attribute; I have not done this yet but it can be
added later fairly easily. Also, I'm not yet serializing the new flag
bit, since it's currently only used internally and I don't know the
ramifications of changing the serialization format; if it's better
that I should go ahead and do so, please let me know.

Note that the new flag is not considered part of the formal type of
the constructor/destructor, since the formal type is (if I understand
correctly) meant to be ABI-independent; instead, the flag is added in
a ABI-specific way after ExtInfo is obtained from the formal type
(similar to how adjustCXXMethodInfo() adjusts the calling convention
in an ABI-specific way.) However, the flag will (I'm anticipating) be
a part of the formal type of library functions that return arguments
when the front-end attribute for marking functions as such is
implemented, since the semantics are ABI-independent in those cases.

For convenience in reviewing, I've split the patch into two parts: a
first part which reverts the current 'this'-return implementation and
a second which implements the new one.

Finally, I was in the process of adding test coverage for MS C++ ABI
cases when I found PR15888
(http://llvm.org/bugs/show_bug.cgi?id=15888), which causes the test to
fail an assert even in an unmodified trunk build. If no one picks that
up I'll take a look myself and try to resolve that so I can add the
test coverage.

Please let me know if you have any comments or suggestions!

-Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: this-return1.patch
Type: application/octet-stream
Size: 16434 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130501/851789cd/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: this-return2.patch
Type: application/octet-stream
Size: 32132 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130501/851789cd/attachment-0001.obj>