trivial_abi

John McCall via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 2 15:33:54 PST 2018


Hey, Richard et al.  Akira and I were talking about the right ABI rule for deciding can-pass-in-registers-ness for structs in the presence of trivial_abi, and I think I like Akira's approach but wanted to get your input.

The current definition in Itanium is:

  non-trivial for the purposes of calls <>
 <>
A type is considered non-trivial for the purposes of calls if:

it has a non-trivial copy constructor, move constructor, or destructor, or
all of its copy and move constructors are deleted.
 <>

I'd suggest modifying this to:

	A type is considered non-trivial for the purposes of calls if:
		- if has a copy constructor, move constructor, or destructor which is non-trivial for the purposes of calls, or
		- all of its copy and move constructors are deleted and it does not have the trivial_abi attribute.

	A copy/move constructor is considered trivial for the purposes of calls if:
		- it is user-provided and
			- the class has the trivial_abi attribute and
			- a defaulted definition of the constructor would be trivial for the purposes of calls; or
		- it is not user-provided and
			- the class has no virtual functions and no virtual base classes, and
			- the constructor used to copy/move each direct base class subobject is trivial for the purposes of calls, and
			- for each non-static data member that is of class type (or array thereof), the constructor selected to copy/move that member is trivial for the purposes of calls.

	A destructor is considered trivial for the purposes of calls if:
		- it is not user-provided or the class has the trivial_abi attribute, and
		- the destructor is not virtual, and
		- all of the direct base classes of its class have destructors that are trivial for the purposes of calls, and
		- for all of the non-static data members of its class that are of class type (or array thereof), each such class is trivial for the purposes of calls.

	These definitions are intended to follow [class.copy.ctor]p11 and [class.dtor]p6 except for the special rules applicable to trivial_abi classes.

I'm not sure about the "defaulted definition" rule for copy/move constructors in trivial_abi classes.  The intent is to allow class temploids with trivial_abi that are instantiated to contain non-trivial classes to just silently become non-trivial.  I was thinking at first that it would be nice to have a general rule that trivial_abi classes only contain trivial_abi subobjects, but unfortunately that's not consistent with the standard triviality rule in some silly corner cases: a trivially-copyable class can have a non-trivially-copyable subobject if it happens to copy that subobject with a trivial copy constructor.  I couldn't think of a better way of capturing this than the "defaulted definition" rule.  I considered using the actual initializers used by the constructor, but that would introduce a lot of new complexity: suddenly we'd be asking about triviality for an arbitrary constructor, and copy/move elision make the question somewhat ambiguous anyway.

I'm also not sure about the right rules about virtual methods.  Should we allow polymorphic classes to be made trivial by application of the attribute?

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


More information about the cfe-commits mailing list