Re: [PATCH] Handle new operators with no arguments in DCE.

[Marc Glisse <marc.glisse@inria.fr>]

On Mon, 5 Aug 2019, Martin Liška wrote:

> You are right. It can really lead to confusion of the DCE.
>
> What we have is DECL_ABSTRACT_ORIGIN(decl) which we can use to indicate operators
> that were somehow modified by an IPA optimization.

Looks similar to the cgraph_node->clone_of that Richard was talking about. 
I have no idea which one would be best.

> Do you believe it will be sufficient?

In DCE only consider the operator delete that are not clones? (possibly 
the same for operator new? I don't know how much we can change the return 
value of a function in a clone) I guess that should work, and it wouldn't 
impact the common case with default, global operator new/delete.

An alternative would be to clear the DECL_IS_OPERATOR_DELETE flag when 
creating a clone (possibly only if it modified the first parameter?). 
There is probably not much information in the fact that a function that 
doesn't even take a pointer used to be an operator delete.


By the way, I just thought of something, now that we handle class-specific 
operator new/delete (but you could do the same with the global replacable 
ones as well):

#include <stdio.h>
int count = 0;
struct A {
   __attribute__((malloc,noinline))
   static void* operator new(unsigned long sz){++count;return ::operator new(sz);}
   static void operator delete(void* ptr){--count;::operator delete(ptr);}
};
int main(){
   delete new A;
   printf("%d\n",count);
}

If we do not inline anything, we can remove the pair and nothing touches 
count. If we inline both new and delete, we can then remove the inner pair 
instead, count increases and decreases, fine. If we inline only one of 
them, and DCE the mismatched pair new/delete, we get something 
inconsistent (count is -1).

This seems to indicate we should check that the new and delete match 
somehow...

-- 
Marc Glisse