Do we need to reopen B1?

[Jason Merrill]

>>>>> Christophe de Dinechin <ddd at cup.hp.com> writes:

 > First:

 > 	For each secondary vtable from a non-virtual base class 'B'
 > 	which defines f, an additional entry point is generated which
 > 	performs the constant adjustment from A* to B*. 

 > So, the intent is indeed that this is a real entry point, with a name
 > and so on, and that it actually converts from _ B* to A* _, correct? And
 > this entry point had a name that you can use to refer to it from other
 > vtables, including in other translation units, correct?

It never occurred to me that it could be otherwise.

 > So: we need to specify that name. Also, let's no longer ever call them
 > 'thunk', since to me a thunk is something that gets emitted with the
 > vtable, not with the target function.

To me, a thunk is a small piece of code that mediates between caller and
callee.  But if you'd rather, we can restrict that term to "traditional",
floating thunks.

 > I was also really sent off track by the note:

 > 	Note that the ABI only specifies the multiple entry points;
 > 	how those entry points are provided is unspecified. An existing
 > 	compiler which uses thunks could be converted to use this ABI by
 > 	only adding support for the vcall offsets. A more efficient
 > 	implementation would be to emit all of the thunks immediately
 > 	before the non-adjusting entry point to the function. Another
 > 	might use predication rather than branches to reach the main
 > 	function. Another might emit a new copy of the function for
 > 	each entry point; this is a quality of implementation issue. 

 > Let me propose a few changes here:

 > 	Note that the ABI only specifies the name and existence of
 > 	multiple entry points. How those entry points are implemented
 > 	is unspecified

This works for me.

 >	, as long as they are emitted with the corresponding
 > 	virtual table.

No; this would disallow emitting them with the function, if the function
and vtable are defined in different places.  I don't think we need to
specify this.

 >      An existing compiler which uses thunks could be
 > 	converted to use this ABI by only adding support for the vcall
 > 	offsets (in the case of virtual inheritance), and by creating
 > 	a named entry point and a thunk for each possible adjustment
 > 	from a secondary base to the derived class (in the case of
 > 	multiple, non-virtual inheritance).

I don't understand "a named entry point and a thunk".  In this case, the
thunk is the entry point.

 > 	A more efficient implementation would be to emit all of the
 > 	adjusting entry points immediately before the non-adjusting
 > 	entry point to the function. Such thunks can also be combined
 > 	in the form of multiple 'Add' instructions that fall through
 > 	to the main entry point.

You used 'thunk'.  :)

 >      Another implementation yet is to use
 > 	predication rather than branches to reach the main function
 > 	[Note: I'm not sure this actually works without a calling
 > 	convention on predicates...].

I had been thinking about something like

foo:
   add *p
   set predicate
bar:
   [if not set] add *q
   ...

but I'd be perfectly happy to lose the predication language.

Jason