RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Richard Smith via cfe-commits]

Do we really need an 'empty type' special case?

The x86_64 psABI already seems clear that empty types with size <= 16
are not passed at all. Following the algorithm in section 3.2.3, each
eightbyte is classified as NO_CLASS, and thus is not passed. So the
proposed change would only affect the behavior of types larger than 16
bytes that contain no data. It doesn't seem worth breaking ABI to more
efficiently pass those.

On Mon, Feb 8, 2016 at 2:35 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Mon, Feb 8, 2016 at 1:40 PM, H.J. Lu <hjl.tools at gmail.com> wrote:
>>
>> On Mon, Feb 8, 2016 at 12:38 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>> > On Mon, Feb 8, 2016 at 12:05 PM, H.J. Lu <hjl.tools at gmail.com> wrote:
>> >>
>> >> On Mon, Feb 8, 2016 at 11:33 AM, Jonathan Wakely <jwakely.gcc at gmail.com>
>> >> wrote:
>> >> > On 8 February 2016 at 19:23, Richard Smith wrote:
>> >> >> "POD for the purpose of layout" is defined in the Itanium C++ ABI here:
>> >> >>
>> >> >>   http://mentorembedded.github.io/cxx-abi/abi.html#definitions
>> >> >
>> >> > Thanks. So there's no problem using "POD for the purposes of layout",
>> >> > and the change to "POD for the purpose of standard-layout" was
>> >> > unnecessary and just confused things.
>> >>
>> >> Here is the revised proposal:
>> >>
>> >> 1. "class type".  A class type is a structure, union or C++ class.
>> >> 2. "empty class type".  An empty class type is:
>> >>    a. A class type without member.  Or
>> >>    b. A class type with only members of empty class types.  Or
>> >
>> >
>> > (a) is a special case of (b).
>> >
>> >>    c. An array of empty class types.
>> >
>> >
>> > It seems confusing to call an array a class type. Instead, how about:
>> >
>> >   2. An empty type is either an array of empty types or a class type where
>> > every member is of empty type.
>> >
>> >> 3. "empty record".  An empty record is Plain Old Data (POD) for the
>> >>    purposes of layout and
>> >>    a. A class type without member.  Or
>> >>    b. A class type with only members of empty class types.
>> >
>> >
>> > (a) is a special case of (b).
>> >
>> >> 4. No memory slot nor register should be used to pass or return an object
>> >> of empty record.
>> >
>> >
>> > Objects of array type are never passed or returned (but if through some
>> > language extension they were, we'd want this rule to apply). So you don't
>> > need rule 3 and this can be just:
>> >
>> >  3. No memory slot nor register should be used to pass or return an object
>> > of empty type.
>>
>> Thanks very much for your inputs.  Here is the proposal:
>>
>> 1. "class type".  A class type is a structure, union or C++ class.
>> 2. "empty type".  An empty type is either an array of empty types or a
>> class type where every member is of empty type.
>> 3. No memory slot nor register should be used to pass or return an object
>> of empty type.
>
> David Majnemer points out that we also need to say something about
> base classes. We could handle that case like this:
>
>  2. "empty type".  An empty type is a type where it and all of its
> subobjects are of class or array type.
>
> Following the C++ rules, this also means that a class that contains
> only unnamed bitfields is empty, because unnamed bitfields are not
> subobjects, but might be worth explicitly stating for the C case. That
> also matches Clang's behavior.