r350920 - [Sema] Make canPassInRegisters return true if the CXXRecordDecl passed

[Akira Hatanaka via cfe-commits]

Would it be better if we disallowed trivial_abi if the class’ copy and move destructors were all deleted (and revert r350920)? I think that would make it easier to reason about when you are allowed to use trivial_abi and what effect the attribute has (which is to override the trivialness for the purpose of calls).

Sorry for my late reply. It took a while to understand that the patch I committed might not be the right way to fix the problem.

> On Jan 16, 2019, at 8:37 PM, John McCall via cfe-commits <cfe-commits at lists.llvm.org> wrote:
> 
> On 16 Jan 2019, at 20:03, Richard Smith wrote:
> 
>> On Wed, 16 Jan 2019 at 16:20, John McCall via cfe-commits <
>> cfe-commits at lists.llvm.org> wrote:
>> 
>>> On 16 Jan 2019, at 18:32, Richard Smith wrote:
>>> 
>>>> On Wed, 16 Jan 2019 at 09:10, John McCall via cfe-commits <
>>>> cfe-commits at lists.llvm.org> wrote:
>>>> 
>>>>> On 16 Jan 2019, at 9:13, Aaron Ballman wrote:
>>>>> 
>>>>>> On Wed, Jan 16, 2019 at 1:57 AM Akira Hatanaka <ahatanaka at apple.com>
>>>>>> wrote:
>>>>>>> 
>>>>>>> Yes, the behavior of the compiler doesn’t match what’s explained
>>>>>>> in the documentation anymore.
>>>>>>> 
>>>>>>> Please take a look at the attached patch, which updates the
>>>>>>> documentation.
>>>>>> 
>>>>>> Patch mostly LGTM, but I did have one wording suggestion.
>>>>>> 
>>>>>>> diff --git a/include/clang/Basic/AttrDocs.td
>>>>>>> b/include/clang/Basic/AttrDocs.td
>>>>>>> index 5773a92c9c..ca3cfcf9b2 100644
>>>>>>> --- a/include/clang/Basic/AttrDocs.td
>>>>>>> +++ b/include/clang/Basic/AttrDocs.td
>>>>>>> @@ -2478,15 +2478,20 @@ def TrivialABIDocs : Documentation {
>>>>>>>   let Category = DocCatVariable;
>>>>>>>   let Content = [{
>>>>>>> The ``trivial_abi`` attribute can be applied to a C++ class, struct,
>>>>>>> or union.
>>>>>>> -It instructs the compiler to pass and return the type using the C
>>>>>>> ABI for the
>>>>>>> +``trivial_abi`` has the following effects:
>>>>>>> +
>>>>>>> +- It instructs the compiler to pass and return the type using the C
>>>>>>> ABI for the
>>>>>>> underlying type when the type would otherwise be considered
>>>>>>> non-trivial for the
>>>>>>> purpose of calls.
>>>>>>> -A class annotated with `trivial_abi` can have non-trivial
>>>>>>> destructors or copy/move constructors without automatically becoming
>>>>>>> non-trivial for the purposes of calls. For example:
>>>>>>> +- It makes the destructor and copy and move constructors of the
>>>>>>> class trivial
>>>>>>> +that would otherwise be considered non-trivial under the C++ ABI
>>>>>>> rules.
>>>>>> 
>>>>>> How about: It makes the destructor, copy constructors, and move
>>>>>> constructors of the class trivial even if they would otherwise be
>>>>>> non-trivial under the C++ ABI rules.
>>>>> 
>>>>> Let's not say that it makes them trivial, because it doesn't.  It causes
>>>>> their immediate non-triviality to be ignored for the purposes of
>>>>> deciding
>>>>> whether the type can be passed in registers.
>>>>> 
>>>> 
>>>> Given the attribute now forces the type to be passed in registers, I
>>> think
>>>> it'd be more to the point to say that it makes the triviality of those
>>>> special members be ignored when deciding whether to pass a type with a
>>>> subobject of this type in registers.
>>> 
>>> Wait, it forces it to be passed in registers?  I thought the design
>>> was that it didn't override the non-trivial-abi-ness of subobjects;
>>> see all the discussion of trivially_relocatable.
>>> 
>> 
>> The attribute is ill-formed if applied to a class that has a subobject that
>> can't be passed in registers (or that has a vptr). And then as a weird
>> special case we don't instantiate the attribute when instantiating a class
>> if it would be ill-formed (well, we instantiate it and then remove it
>> again, but the effect is the same).
>> 
>> The commit at the start of this email chain switches us from the "just
>> override the trivialness for the purposes of the ABI" model to /also/
>> forcing the type to be passed in registers (the type would otherwise not be
>> passed in registers in some corner cases, such as if all its copy/move
>> special members are deleted).
> 
> I see.  Alright, I accept your wording, then.
> 
> John.
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org <mailto:cfe-commits at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20190131/3e878864/attachment-0001.html>