On Tue, 9 Jul 2019, Marc Glisse wrote:
On Mon, 8 Jul 2019, Martin Liška wrote:
The patch apparently has DECL_IS_OPERATOR_DELETE only on the replaceable
global deallocation functions, not all delete operators, contrary to
DECL_IS_OPERATOR_NEW, so the name is misleading. On the other hand, those
seem to be the ones for which the optimization is legal (well, not quite,
the rules are in terms of operator new, and I am not sure how well
operator delete has to match, but close enough).
Are you talking about this location where we set OPERATOR_NEW:
https://github.com/gcc-mirror/gcc/blob/master/gcc/cp/decl.c#L13643
?
That's the only place where we set OPERATOR_NEW flag and not
OPERATOR_DELETE.
Yes, I think that's the place.
Again, not setting DECL_IS_OPERATOR_DELETE on local operator delete
seems misleading, but setting it would let us optimize in cases where we
are not really allowed to. Maybe just rename your macro to
DECL_IS_GLOBAL_OPERATOR_DELETE?
Hmm, I replied too fast.
Global operator delete does not seem like a good terminology, the ones
marked in the patch would be the usual (=non-placement) replaceable
deallocation functions.
I cannot find a requirement that operator new and operator delete should
match. The rules to omit allocation are stated in terms of which operator
new is called, but do not seem to care which operator delete is used. So
allocating with the global operator new and deallocating with a class
overload of operator delete can be removed, but not the reverse (not sure
how they came up with such a rule...). Which means we would need:
keep DECL_IS_OPERATOR_NEW for the current uses
DECL_IS_REPLACEABLE_OPERATOR_NEW (equivalent to DECL_IS_OPERATOR_NEW &&
DECL_IS_MALLOC? not exactly but close I think) for DCE
DECL_IS_OPERATOR_DELETE (which also includes some class overloads) for DCE
Maybe we can ignore the class-specific operator delete if it simplifies
things.
Sorry for the messy comments, the messy rules don't help...
--
Marc Glisse
