This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Handle new operators with no arguments in DCE.
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