Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Marc Glisse]

On Wed, 29 Nov 2017, David Malcolm wrote:


I was experimenting with optimizing away matching malloc/free pairs,
moving the allocation to either the stack, or to a thread-local
obstack, under certain conditions, or to hoist allocations out of
loops.

I didn't get any significant wins, but much of this was due to my lack
of experience with the middle-end, and being drawn back to front-
end/diagnostic improvements.


Hello,

could you share what you have? Is this something you might work on again 
at some point?


I had a go (very limited) at this problem some years ago, and would be 
interested in looking at your approach.


--
Marc Glisse

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Trevor Saunders]

On Wed, Nov 29, 2017 at 08:56:44AM -0700, Martin Sebor wrote:
> On 11/29/2017 01:30 AM, Jakub Jelinek wrote:
> > On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote:
> > > On 11/27/2017 02:22 AM, Dominik Inführ wrote:
> > > > Thanks for all the reviews! I’ve revised the patch, the 
> > > > operator_delete_flag is now stored in tree_decl_with_vis (there already 
> > > > seem to be some FUNCTION_DECL-flags in there). I’ve also added the 
> > > > option -fallocation-dce to disable this optimization. It bootstraps and 
> > > > no regressions on aarch64 and x86_64.
> > > > 
> > > It's great to be able to eliminate pairs of these calls.  For
> > > unpaired calls, though, I think it would be even more useful to
> > > also issue a warning.  Otherwise the elimination will mask bugs
> > 
> > ??  I hope you're only talking about allocation where the returned
> > pointer can't leak elsewhere, doing allocation in one function
> > (e.g. constructor, or whatever other function) and deallocation in some
> > other one is so common such a warning would be not just useless, but
> > harmful with almost all occurrences being false positives.
> > 
> > Warning on malloc/standard operator new or malloc/realloc-like function
> > when the return pointer can't escape the current function is reasonable.
> 
> Yes, warn for leaks, or for calls to delete/free with no matching
> new/malloc (when they can be detected).
> 
> From the test case included in the patch, warn on the first two
> of the following three functions:
> 
> +++ b/gcc/testsuite/g++.dg/cpp1y/new1.C
> @@ -0,0 +1,65 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-cddce-details" } */
> +
> +#include 
> +
> +void
> +new_without_use() {
> +  int *x = new int;
> +}
> +
> +void
> +new_array_without_use() {
> +  int *x = new int[5];
> +}
> +
> +void
> +new_primitive() {
> +  int *x = new int;
> +  delete x;
> +}
> 
> An obvious extension to such a checker would then be to also detect
> possible invalid deallocations, as in:
> 
>   void f (unsigned n)
>   {
> void *p = n < 256 ? alloca (n) : malloc (n);
> // ...
> free (p);
>   }
> 
> David Malcolm was working on something like that earlier this year
> so he might have some thoughts on this as well.

I also sent https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00491.html a
while back, sorry I haven't gotten to  improving it yet though its gcc 9
stuff at this point I guess.

thanks

Trev

> 
> Martin

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Jeff Law]

On 11/29/2017 01:30 AM, Jakub Jelinek wrote:
> On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote:
>> On 11/27/2017 02:22 AM, Dominik Inführ wrote:
>>> Thanks for all the reviews! I’ve revised the patch, the 
>>> operator_delete_flag is now stored in tree_decl_with_vis (there already 
>>> seem to be some FUNCTION_DECL-flags in there). I’ve also added the option 
>>> -fallocation-dce to disable this optimization. It bootstraps and no 
>>> regressions on aarch64 and x86_64.
>>>
>> It's great to be able to eliminate pairs of these calls.  For
>> unpaired calls, though, I think it would be even more useful to
>> also issue a warning.  Otherwise the elimination will mask bugs
> 
> ??  I hope you're only talking about allocation where the returned
> pointer can't leak elsewhere, doing allocation in one function
> (e.g. constructor, or whatever other function) and deallocation in some
> other one is so common such a warning would be not just useless, but
> harmful with almost all occurrences being false positives.
> 
> Warning on malloc/standard operator new or malloc/realloc-like function
> when the return pointer can't escape the current function is reasonable.
That's probably a special enough case to be worth a warning
(non-escaping without deallocation).

My comments about needing a stronger analysis engine were for the more
general problem of resource leak detection.

jeff

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Jeff Law]

On 11/28/2017 09:11 PM, Martin Sebor wrote:
> On 11/27/2017 02:22 AM, Dominik Inführ wrote:
>> Thanks for all the reviews! I’ve revised the patch, the
>> operator_delete_flag is now stored in tree_decl_with_vis (there
>> already seem to be some FUNCTION_DECL-flags in there). I’ve also added
>> the option -fallocation-dce to disable this optimization. It
>> bootstraps and no regressions on aarch64 and x86_64.
>>
> It's great to be able to eliminate pairs of these calls.  For
> unpaired calls, though, I think it would be even more useful to
> also issue a warning.  Otherwise the elimination will mask bugs
> that might only show up without optimization, or with other
> compilers (such as older versions of GCC).  I realize GCC doesn't
> warn for these bugs involving malloc, but I think it should for
> the same reason.
Aldy and I looked at this stuff a while ago -- to do anything reasonable
you have to build a much stronger static analysis engine than we've got
in GCC right now.  THe false positive rate will be way too high to be
useful on real world code.

I don't see how the optimizatino changes anything WRT warnings though.
If you don't have a clear pair where all the proper preconditions are
met, then you don't do anything.  Those preconditions would include that
you actually have a pair as opposed to just the allocation point.


Jeff

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Richard Biener]

On November 29, 2017 4:56:44 PM GMT+01:00, Martin Sebor  
wrote:
>On 11/29/2017 01:30 AM, Jakub Jelinek wrote:
>> On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote:
>>> On 11/27/2017 02:22 AM, Dominik Inführ wrote:
 Thanks for all the reviews! I’ve revised the patch, the
>operator_delete_flag is now stored in tree_decl_with_vis (there already
>seem to be some FUNCTION_DECL-flags in there). I’ve also added the
>option -fallocation-dce to disable this optimization. It bootstraps and
>no regressions on aarch64 and x86_64.

>>> It's great to be able to eliminate pairs of these calls.  For
>>> unpaired calls, though, I think it would be even more useful to
>>> also issue a warning.  Otherwise the elimination will mask bugs
>>
>> ??  I hope you're only talking about allocation where the returned
>> pointer can't leak elsewhere, doing allocation in one function
>> (e.g. constructor, or whatever other function) and deallocation in
>some
>> other one is so common such a warning would be not just useless, but
>> harmful with almost all occurrences being false positives.
>>
>> Warning on malloc/standard operator new or malloc/realloc-like
>function
>> when the return pointer can't escape the current function is
>reasonable.
>
>Yes, warn for leaks, or for calls to delete/free with no matching
>new/malloc (when they can be detected).
>
> From the test case included in the patch, warn on the first two
>of the following three functions:
>
>+++ b/gcc/testsuite/g++.dg/cpp1y/new1.C
>@@ -0,0 +1,65 @@
>+/* { dg-do compile } */
>+/* { dg-options "-O2 -fdump-tree-cddce-details" } */
>+
>+#include 
>+
>+void
>+new_without_use() {
>+  int *x = new int;
>+}
>+
>+void
>+new_array_without_use() {
>+  int *x = new int[5];
>+}
>+
>+void
>+new_primitive() {
>+  int *x = new int;
>+  delete x;
>+}
>
>An obvious extension to such a checker would then be to also detect
>possible invalid deallocations, as in:
>
>   void f (unsigned n)
>   {
> void *p = n < 256 ? alloca (n) : malloc (n);
> // ...
> free (p);
>   }
>
>David Malcolm was working on something like that earlier this year
>so he might have some thoughts on this as well.

Or

P = new x;
Free (P) ;

Richard. 

>Martin

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Andrew Pinski]

On Wed, Nov 29, 2017 at 8:15 AM, David Malcolm  wrote:
> On Wed, 2017-11-29 at 08:56 -0700, Martin Sebor wrote:
>> On 11/29/2017 01:30 AM, Jakub Jelinek wrote:
>> > On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote:
>> > > On 11/27/2017 02:22 AM, Dominik Inführ wrote:
>> > > > Thanks for all the reviews! I’ve revised the patch, the
>> > > > operator_delete_flag is now stored in tree_decl_with_vis (there
>> > > > already seem to be some FUNCTION_DECL-flags in there). I’ve
>> > > > also added the option -fallocation-dce to disable this
>> > > > optimization. It bootstraps and no regressions on aarch64 and
>> > > > x86_64.
>> > > >
>> > >
>> > > It's great to be able to eliminate pairs of these calls.  For
>> > > unpaired calls, though, I think it would be even more useful to
>> > > also issue a warning.  Otherwise the elimination will mask bugs
>> >
>> > ??  I hope you're only talking about allocation where the returned
>> > pointer can't leak elsewhere, doing allocation in one function
>> > (e.g. constructor, or whatever other function) and deallocation in
>> > some
>> > other one is so common such a warning would be not just useless,
>> > but
>> > harmful with almost all occurrences being false positives.
>> >
>> > Warning on malloc/standard operator new or malloc/realloc-like
>> > function
>> > when the return pointer can't escape the current function is
>> > reasonable.
>>
>> Yes, warn for leaks, or for calls to delete/free with no matching
>> new/malloc (when they can be detected).
>>
>>  From the test case included in the patch, warn on the first two
>> of the following three functions:
>>
>> +++ b/gcc/testsuite/g++.dg/cpp1y/new1.C
>> @@ -0,0 +1,65 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2 -fdump-tree-cddce-details" } */
>> +
>> +#include 
>> +
>> +void
>> +new_without_use() {
>> +  int *x = new int;
>> +}
>> +
>> +void
>> +new_array_without_use() {
>> +  int *x = new int[5];
>> +}
>> +
>> +void
>> +new_primitive() {
>> +  int *x = new int;
>> +  delete x;
>> +}
>>
>> An obvious extension to such a checker would then be to also detect
>> possible invalid deallocations, as in:
>>
>>void f (unsigned n)
>>{
>>  void *p = n < 256 ? alloca (n) : malloc (n);
>>  // ...
>>  free (p);
>>}
>>
>> David Malcolm was working on something like that earlier this year
>> so he might have some thoughts on this as well.
>
> I was experimenting with optimizing away matching malloc/free pairs,
> moving the allocation to either the stack, or to a thread-local
> obstack, under certain conditions, or to hoist allocations out of
> loops.
>
> I didn't get any significant wins, but much of this was due to my lack
> of experience with the middle-end, and being drawn back to front-
> end/diagnostic improvements.
>
> Issues I ran into included:
>
> * wrapper functions like "Perl_malloc" which require LTO for the
> optimization to be able to see the allocations
>
> * 435.gromacs has this "interesting" function:

It is still in the upstream sources too:
https://sourcecodebrowser.com/gromacs/3.3.1/smalloc_8h.html#a776f070172af6850dda887c7358fa630

Thanks,
Andrew Pinski

>
>   unsigned maxavail(void)
>   {
> char *ptr;
> unsigned low,high,size;
>
> low=0;
> high=256e6;
> while ((high-low) > 4) {
>   size=(high+low)/2;
>   if ((ptr=malloc((size_t)size))==NULL)
> high=size;
>   else {
> free(ptr);
> low=size;
>   }
> }
> return low;
>   }
>
>   i.e. a loop which attempts a binary search of malloc calls to try to
> find a threshold at which they fail.
>
>
> Dave

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[David Malcolm]

On Wed, 2017-11-29 at 08:56 -0700, Martin Sebor wrote:
> On 11/29/2017 01:30 AM, Jakub Jelinek wrote:
> > On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote:
> > > On 11/27/2017 02:22 AM, Dominik Inführ wrote:
> > > > Thanks for all the reviews! I’ve revised the patch, the
> > > > operator_delete_flag is now stored in tree_decl_with_vis (there
> > > > already seem to be some FUNCTION_DECL-flags in there). I’ve
> > > > also added the option -fallocation-dce to disable this
> > > > optimization. It bootstraps and no regressions on aarch64 and
> > > > x86_64.
> > > > 
> > > 
> > > It's great to be able to eliminate pairs of these calls.  For
> > > unpaired calls, though, I think it would be even more useful to
> > > also issue a warning.  Otherwise the elimination will mask bugs
> > 
> > ??  I hope you're only talking about allocation where the returned
> > pointer can't leak elsewhere, doing allocation in one function
> > (e.g. constructor, or whatever other function) and deallocation in
> > some
> > other one is so common such a warning would be not just useless,
> > but
> > harmful with almost all occurrences being false positives.
> > 
> > Warning on malloc/standard operator new or malloc/realloc-like
> > function
> > when the return pointer can't escape the current function is
> > reasonable.
> 
> Yes, warn for leaks, or for calls to delete/free with no matching
> new/malloc (when they can be detected).
> 
>  From the test case included in the patch, warn on the first two
> of the following three functions:
> 
> +++ b/gcc/testsuite/g++.dg/cpp1y/new1.C
> @@ -0,0 +1,65 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-cddce-details" } */
> +
> +#include 
> +
> +void
> +new_without_use() {
> +  int *x = new int;
> +}
> +
> +void
> +new_array_without_use() {
> +  int *x = new int[5];
> +}
> +
> +void
> +new_primitive() {
> +  int *x = new int;
> +  delete x;
> +}
> 
> An obvious extension to such a checker would then be to also detect
> possible invalid deallocations, as in:
> 
>void f (unsigned n)
>{
>  void *p = n < 256 ? alloca (n) : malloc (n);
>  // ...
>  free (p);
>}
> 
> David Malcolm was working on something like that earlier this year
> so he might have some thoughts on this as well.

I was experimenting with optimizing away matching malloc/free pairs,
moving the allocation to either the stack, or to a thread-local
obstack, under certain conditions, or to hoist allocations out of
loops.  

I didn't get any significant wins, but much of this was due to my lack
of experience with the middle-end, and being drawn back to front-
end/diagnostic improvements.

Issues I ran into included:

* wrapper functions like "Perl_malloc" which require LTO for the
optimization to be able to see the allocations

* 435.gromacs has this "interesting" function:

  unsigned maxavail(void)
  {
char *ptr;
unsigned low,high,size;
  
low=0;
high=256e6;
while ((high-low) > 4) {
  size=(high+low)/2;
  if ((ptr=malloc((size_t)size))==NULL)
high=size;
  else {
free(ptr);
low=size;
  }
}
return low;
  }

  i.e. a loop which attempts a binary search of malloc calls to try to
find a threshold at which they fail.


Dave

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Martin Sebor]

On 11/29/2017 01:30 AM, Jakub Jelinek wrote:

On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote:

On 11/27/2017 02:22 AM, Dominik Inführ wrote:

Thanks for all the reviews! I’ve revised the patch, the operator_delete_flag is 
now stored in tree_decl_with_vis (there already seem to be some 
FUNCTION_DECL-flags in there). I’ve also added the option -fallocation-dce to 
disable this optimization. It bootstraps and no regressions on aarch64 and 
x86_64.


It's great to be able to eliminate pairs of these calls.  For
unpaired calls, though, I think it would be even more useful to
also issue a warning.  Otherwise the elimination will mask bugs


??  I hope you're only talking about allocation where the returned
pointer can't leak elsewhere, doing allocation in one function
(e.g. constructor, or whatever other function) and deallocation in some
other one is so common such a warning would be not just useless, but
harmful with almost all occurrences being false positives.

Warning on malloc/standard operator new or malloc/realloc-like function
when the return pointer can't escape the current function is reasonable.


Yes, warn for leaks, or for calls to delete/free with no matching
new/malloc (when they can be detected).

From the test case included in the patch, warn on the first two
of the following three functions:

+++ b/gcc/testsuite/g++.dg/cpp1y/new1.C
@@ -0,0 +1,65 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-cddce-details" } */
+
+#include 
+
+void
+new_without_use() {
+  int *x = new int;
+}
+
+void
+new_array_without_use() {
+  int *x = new int[5];
+}
+
+void
+new_primitive() {
+  int *x = new int;
+  delete x;
+}

An obvious extension to such a checker would then be to also detect
possible invalid deallocations, as in:

  void f (unsigned n)
  {
void *p = n < 256 ? alloca (n) : malloc (n);
// ...
free (p);
  }

David Malcolm was working on something like that earlier this year
so he might have some thoughts on this as well.

Martin

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Jakub Jelinek]

On Tue, Nov 28, 2017 at 09:11:00PM -0700, Martin Sebor wrote:
> On 11/27/2017 02:22 AM, Dominik Inführ wrote:
> > Thanks for all the reviews! I’ve revised the patch, the 
> > operator_delete_flag is now stored in tree_decl_with_vis (there already 
> > seem to be some FUNCTION_DECL-flags in there). I’ve also added the option 
> > -fallocation-dce to disable this optimization. It bootstraps and no 
> > regressions on aarch64 and x86_64.
> > 
> It's great to be able to eliminate pairs of these calls.  For
> unpaired calls, though, I think it would be even more useful to
> also issue a warning.  Otherwise the elimination will mask bugs

??  I hope you're only talking about allocation where the returned
pointer can't leak elsewhere, doing allocation in one function
(e.g. constructor, or whatever other function) and deallocation in some
other one is so common such a warning would be not just useless, but
harmful with almost all occurrences being false positives.

Warning on malloc/standard operator new or malloc/realloc-like function
when the return pointer can't escape the current function is reasonable.

Jakub

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Martin Sebor]

On 11/27/2017 02:22 AM, Dominik Inführ wrote:

Thanks for all the reviews! I’ve revised the patch, the operator_delete_flag is 
now stored in tree_decl_with_vis (there already seem to be some 
FUNCTION_DECL-flags in there). I’ve also added the option -fallocation-dce to 
disable this optimization. It bootstraps and no regressions on aarch64 and 
x86_64.


It's great to be able to eliminate pairs of these calls.  For
unpaired calls, though, I think it would be even more useful to
also issue a warning.  Otherwise the elimination will mask bugs
that might only show up without optimization, or with other
compilers (such as older versions of GCC).  I realize GCC doesn't
warn for these bugs involving malloc, but I think it should for
the same reason.


The problem with this patch is what Marc noticed: it omits too many allocations. The 
C++ standard seems to only allow to omit "replaceable global allocation 
functions (18.6.1.1, 18.6.1.2)”. So e.g. no class-specific or user-defined 
allocations. I am not sure what’s the best way to implement this. Just checking the 
function declarations might not be enough and seems more like a hack. The better way 
seems to introduce a __builtin_operator_new like Marc mentioned. In which way would 
you implement this? Could you please give me some pointers here to look at?


I'm not sure there is a way to do it other than by comparing
the name.  To see where to insert the built-in and when, you
might want to look at cp/init.c.

Martin



Thanks,
Dominik





On 22 Nov 2017, at 11:37, Jakub Jelinek  wrote:

On Wed, Nov 22, 2017 at 10:30:29AM +0100, Richard Biener wrote:

--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1787,7 +1787,9 @@ struct GTY(()) tree_function_decl {
  unsigned has_debug_args_flag : 1;
  unsigned tm_clone_flag : 1;
  unsigned versioned_function : 1;
-  /* No bits left.  */
+
+  unsigned operator_delete_flag : 1;
+  /* 31 bits left.  */

while it looks bad reality is that on 64bit pointer hosts we had 32 bits left.


But we can just add it to say tree_decl_common which has 14 spare bits or
tree_decl_with_vis which has another 14 spare bits.  By just noting the flag
applies only to FUNCTION_DECLs and enforcing it in the tree.h macros,
it will be easy to reuse that bit for something different for trees other
than FUNCTION_DECL.

Jakub

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Jakub Jelinek]

On Tue, Nov 28, 2017 at 12:52:12PM +0100, Richard Biener wrote:
> On Mon, Nov 27, 2017 at 5:58 PM, Jeff Law  wrote:
> > On 11/27/2017 02:22 AM, Dominik Inführ wrote:
> >> Thanks for all the reviews! I’ve revised the patch, the 
> >> operator_delete_flag is now stored in tree_decl_with_vis (there already 
> >> seem to be some FUNCTION_DECL-flags in there). I’ve also added the option 
> >> -fallocation-dce to disable this optimization. It bootstraps and no 
> >> regressions on aarch64 and x86_64.
> >>
> >> The problem with this patch is what Marc noticed: it omits too many 
> >> allocations. The C++ standard seems to only allow to omit "replaceable 
> >> global allocation functions (18.6.1.1, 18.6.1.2)”. So e.g. no 
> >> class-specific or user-defined allocations. I am not sure what’s the best 
> >> way to implement this. Just checking the function declarations might not 
> >> be enough and seems more like a hack. The better way seems to introduce a 
> >> __builtin_operator_new like Marc mentioned. In which way would you 
> >> implement this? Could you please give me some pointers here to look at?
> > Just a nit.  Make sure to mention BZ 23383 in your ChangeLog entry.
> > Like this:
> >
> > c++/23383
> > * tree-core.h (blah blah): What changed.
> >
> >
> > Jakub and Richi probably have a better understanding of the builtin
> > mechanisms than I do.  I'll leave it for them to comment on how best to
> > proceed there.
> 
> I don't see why a builtin is necessary, can the FE not see which one
> is the global allocation function?

It should, and finding it by namespace and name is IMHO not a hack,
that is how the C++ standard specifies those.

> Anyways, there are no FE specific builtins, traditionally FEs have
> used special keywords - you might
> want to search for RID_BUILTIN_LAUNDER for example.

Those are there just for parsing them, there is nothing special needed
to parse the standard new/delete operators.

Jakub

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Richard Biener]

On Mon, Nov 27, 2017 at 5:58 PM, Jeff Law  wrote:
> On 11/27/2017 02:22 AM, Dominik Inführ wrote:
>> Thanks for all the reviews! I’ve revised the patch, the operator_delete_flag 
>> is now stored in tree_decl_with_vis (there already seem to be some 
>> FUNCTION_DECL-flags in there). I’ve also added the option -fallocation-dce 
>> to disable this optimization. It bootstraps and no regressions on aarch64 
>> and x86_64.
>>
>> The problem with this patch is what Marc noticed: it omits too many 
>> allocations. The C++ standard seems to only allow to omit "replaceable 
>> global allocation functions (18.6.1.1, 18.6.1.2)”. So e.g. no class-specific 
>> or user-defined allocations. I am not sure what’s the best way to implement 
>> this. Just checking the function declarations might not be enough and seems 
>> more like a hack. The better way seems to introduce a __builtin_operator_new 
>> like Marc mentioned. In which way would you implement this? Could you please 
>> give me some pointers here to look at?
> Just a nit.  Make sure to mention BZ 23383 in your ChangeLog entry.
> Like this:
>
> c++/23383
> * tree-core.h (blah blah): What changed.
>
>
> Jakub and Richi probably have a better understanding of the builtin
> mechanisms than I do.  I'll leave it for them to comment on how best to
> proceed there.

I don't see why a builtin is necessary, can the FE not see which one
is the global allocation function?
Anyways, there are no FE specific builtins, traditionally FEs have
used special keywords - you might
want to search for RID_BUILTIN_LAUNDER for example.

Richard.

> jeff

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Jeff Law]

On 11/27/2017 02:22 AM, Dominik Inführ wrote:
> Thanks for all the reviews! I’ve revised the patch, the operator_delete_flag 
> is now stored in tree_decl_with_vis (there already seem to be some 
> FUNCTION_DECL-flags in there). I’ve also added the option -fallocation-dce to 
> disable this optimization. It bootstraps and no regressions on aarch64 and 
> x86_64.
> 
> The problem with this patch is what Marc noticed: it omits too many 
> allocations. The C++ standard seems to only allow to omit "replaceable global 
> allocation functions (18.6.1.1, 18.6.1.2)”. So e.g. no class-specific or 
> user-defined allocations. I am not sure what’s the best way to implement 
> this. Just checking the function declarations might not be enough and seems 
> more like a hack. The better way seems to introduce a __builtin_operator_new 
> like Marc mentioned. In which way would you implement this? Could you please 
> give me some pointers here to look at?
Just a nit.  Make sure to mention BZ 23383 in your ChangeLog entry.
Like this:

c++/23383
* tree-core.h (blah blah): What changed.


Jakub and Richi probably have a better understanding of the builtin
mechanisms than I do.  I'll leave it for them to comment on how best to
proceed there.

jeff

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Jakub Jelinek]

On Mon, Nov 27, 2017 at 10:22:52AM +0100, Dominik Inführ wrote:
> @@ -4195,8 +4198,10 @@ cxx_init_decl_processing (void)
>   deltype = cp_build_type_attribute_variant (void_ftype_ptr_size,
>  extvisattr);
>   deltype = build_exception_variant (deltype, empty_except_spec);
> - push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW);
> + opdel = push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW);
> + DECL_IS_OPERATOR_DELETE (opdel) = 1;
>   push_cp_library_fn (VEC_DELETE_EXPR, deltype, ECF_NOTHROW);

Missing "opdel = " above.

> + DECL_IS_OPERATOR_DELETE (opdel) = 1;
>}
>  
>  if (aligned_new_threshold)


Jakub

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Dominik Inführ]

Thanks for all the reviews! I’ve revised the patch, the operator_delete_flag is 
now stored in tree_decl_with_vis (there already seem to be some 
FUNCTION_DECL-flags in there). I’ve also added the option -fallocation-dce to 
disable this optimization. It bootstraps and no regressions on aarch64 and 
x86_64.

The problem with this patch is what Marc noticed: it omits too many 
allocations. The C++ standard seems to only allow to omit "replaceable global 
allocation functions (18.6.1.1, 18.6.1.2)”. So e.g. no class-specific or 
user-defined allocations. I am not sure what’s the best way to implement this. 
Just checking the function declarations might not be enough and seems more like 
a hack. The better way seems to introduce a __builtin_operator_new like Marc 
mentioned. In which way would you implement this? Could you please give me some 
pointers here to look at?

Thanks,
Dominik

diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index d95a2b6ea4f..4ed8c2d191a 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -2454,6 +2454,7 @@ merge_decls (tree newdecl, tree olddecl, tree newtype, 
tree oldtype)
  TREE_THIS_VOLATILE (newdecl) |= TREE_THIS_VOLATILE (olddecl);
  DECL_IS_MALLOC (newdecl) |= DECL_IS_MALLOC (olddecl);
  DECL_IS_OPERATOR_NEW (newdecl) |= DECL_IS_OPERATOR_NEW (olddecl);
+ DECL_IS_OPERATOR_DELETE (newdecl) |= DECL_IS_OPERATOR_DELETE 
(olddecl);
  TREE_READONLY (newdecl) |= TREE_READONLY (olddecl);
  DECL_PURE_P (newdecl) |= DECL_PURE_P (olddecl);
  DECL_IS_NOVOPS (newdecl) |= DECL_IS_NOVOPS (olddecl);
diff --git a/gcc/common.opt b/gcc/common.opt
index f8f2ed3db8a..526c7df63d7 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2119,6 +2119,10 @@ starts and when the destructor finishes.
 flifetime-dse=
 Common Joined RejectNegative UInteger Var(flag_lifetime_dse) Optimization 
IntegerRange(0, 2)
 
+fallocation-dce
+Common Report Var(flag_allocation_dce) Init(1) Optimization
+Tell DCE to remove unused C++ allocations.
+
 flive-range-shrinkage
 Common Report Var(flag_live_range_shrinkage) Init(0) Optimization
 Relief of register pressure through live range shrinkage.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 54e06568e46..d1c77b1d670 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -4182,8 +4182,11 @@ cxx_init_decl_processing (void)
 opnew = push_cp_library_fn (VEC_NEW_EXPR, newtype, 0);
 DECL_IS_MALLOC (opnew) = 1;
 DECL_IS_OPERATOR_NEW (opnew) = 1;
-push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW);
-push_cp_library_fn (VEC_DELETE_EXPR, deltype, ECF_NOTHROW);
+tree opdel = push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW);
+DECL_IS_OPERATOR_DELETE (opdel) = 1;
+opdel = push_cp_library_fn (VEC_DELETE_EXPR, deltype, ECF_NOTHROW);
+DECL_IS_OPERATOR_DELETE (opdel) = 1;
+
 if (flag_sized_deallocation)
   {
/* Also push the sized deallocation variants:
@@ -4195,8 +4198,10 @@ cxx_init_decl_processing (void)
deltype = cp_build_type_attribute_variant (void_ftype_ptr_size,
   extvisattr);
deltype = build_exception_variant (deltype, empty_except_spec);
-   push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW);
+   opdel = push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW);
+   DECL_IS_OPERATOR_DELETE (opdel) = 1;
push_cp_library_fn (VEC_DELETE_EXPR, deltype, ECF_NOTHROW);
+   DECL_IS_OPERATOR_DELETE (opdel) = 1;
   }
 
 if (aligned_new_threshold)
@@ -4224,8 +4229,10 @@ cxx_init_decl_processing (void)
align_type_node, NULL_TREE);
deltype = cp_build_type_attribute_variant (deltype, extvisattr);
deltype = build_exception_variant (deltype, empty_except_spec);
-   push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW);
-   push_cp_library_fn (VEC_DELETE_EXPR, deltype, ECF_NOTHROW);
+   opdel = push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW);
+   DECL_IS_OPERATOR_DELETE (opdel) = 1;
+   opdel = push_cp_library_fn (VEC_DELETE_EXPR, deltype, ECF_NOTHROW);
+   DECL_IS_OPERATOR_DELETE (opdel) = 1;
 
if (flag_sized_deallocation)
  {
@@ -4235,8 +4242,10 @@ cxx_init_decl_processing (void)
NULL_TREE);
deltype = cp_build_type_attribute_variant (deltype, extvisattr);
deltype = build_exception_variant (deltype, empty_except_spec);
-   push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW);
-   push_cp_library_fn (VEC_DELETE_EXPR, deltype, ECF_NOTHROW);
+   opdel = push_cp_library_fn (DELETE_EXPR, deltype, ECF_NOTHROW);
+   DECL_IS_OPERATOR_DELETE (opdel) = 1;
+   opdel = push_cp_library_fn (VEC_DELETE_EXPR, deltype, ECF_NOTHROW);
+   DECL_IS_OPERATOR_DELETE (opdel) = 1;
  }
   }
 
diff --git a/gcc/gimple.c b/gcc/gimple.c
index c986a732004..b4cce195e57 100644
--- 

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Marc Glisse]

(please try to convince your mailer to use something other than 
Content-Type: application/octet-stream for a patch)


On Tue, 21 Nov 2017, Dominik Inführ wrote:

this patch tries to extend tree-ssa-dce.c to remove unnecessary 
new/delete-pairs (it already does that for malloc/free). Clang does it 
too and it seems to be allowed by 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html. I’ve 
bootstrapped/regtested on aarch64-linux and x86_64-linux.


In clang, they (i.e. more or less the authors of the paper you mention) 
went through the trouble of introducing __builtin_operator_new 
specifically so not all calls to operator new were affected, but 
essentially only the calls to the global operator new that come from new 
expressions or from std::allocator. This appears to be a deliberate change 
between N3537 and N3664, although I did not find the rationale.


So you might want to check with the committee if optimizing more calls is 
ok.


--
Marc Glisse

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Jeff Law]

On 11/22/2017 03:31 AM, Martin Jambor wrote:
> On Tue, Nov 21 2017, Jeff Law wrote:
>> On 11/21/2017 04:14 AM, Dominik Inführ wrote:
>>> Hi,
>>>
>>> this patch tries to extend tree-ssa-dce.c to remove unnecessary 
>>> new/delete-pairs (it already does that for malloc/free). Clang does it too 
>>> and it seems to be allowed by 
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html. I’ve 
>>> bootstrapped/regtested on aarch64-linux and x86_64-linux.
>> Just a note, we've transitioned into stage3 in preparation for the
>> upcoming gcc-8 release in the spring.  During stage3 we're addressing
>> bugfixes, not further enhancements (with the exception of enhancements
>> that were posted prior to stage1 close).
>>
>> So it's unlikely anyone will dig into this right now, unless there's an
>> existing bugzilla around this missed optimization.
> 
> Unless I am mistaken, I think it is PR 23383
I think 23383 touches on some of these issues, but I'm not sure it's the
same thing.  Marking new with the malloc attribute should in theory be
all that's necessary to address the original issue in 23383.

Marking *should* allow the alias analysis code to disambiguate "a" and
"b" and in turn allow us to determine that the return value is always
"1".  That's the crux of 23383.

The final comment notes we can omit the calls which is good as it gives
us freedom in c++14 mode.   I'm going to assume that the requirement is
that we have to provide suitable space either on the stack, in a
register or within another object and that removal of that additional
space is valid if we determine it's actually not needed.

Anyway, 23383 is likely a piece what's done with this patch.  Namely
that with this patch we'd likely wipe out the new/delete pair for "b" as
the value is never used and never escapes.  Then we'd probably do the
same for "a".  But ISTM this is beyond what the BZ was complaining about.


You could make the argument that the marking done by the patch should go
in under 23383, that seems pretty easy.  You might then argue that the
DCE extension is a trivial extension of that work, trivial enough that
it could be considered under the umbrella of 23383.

Jeff



> 
> Martin
> 

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Nathan Sidwell]

On 11/22/2017 08:59 AM, Richard Biener wrote:


Anything else can be done as followup and need not be done as part of
this patch.  An enum for
this would work I guess.


I've added this to https://gcc.gnu.org/wiki/ImprovementProjects:

Compress DECL flags

tree-core defines a number of bit flags (DECL_IS_MALLOC, 
DECL_IS_OPERATOR_NEW, DECL_CONSTRUCTOR, DECL_STATIC_CONSTRUCTOR, etc) 
that are mutually exclusive. It would be better to use some kind of 
enumeration, rather than individual flags. (We've run out of bits). 
(Suggested by Richard Biener & Nathan Sidwell)


[The reason I put names on these things, is so there's someone to 
contact if the intent isn't clear]


nathan

--
Nathan Sidwell

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Richard Biener]

On Wed, Nov 22, 2017 at 1:47 PM, Nathan Sidwell  wrote:
> On 11/21/2017 06:14 AM, Dominik Inführ wrote:
>>
>> Hi,
>>
>> this patch tries to extend tree-ssa-dce.c to remove unnecessary
>> new/delete-pairs (it already does that for malloc/free). Clang does it too
>> and it seems to be allowed by
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html. I’ve
>> bootstrapped/regtested on aarch64-linux and x86_64-linux.
>
>
> nice.
>
>> --- a/gcc/tree-core.h
>> +++ b/gcc/tree-core.h
>> @@ -1787,7 +1787,9 @@ struct GTY(()) tree_function_decl {
>>unsigned has_debug_args_flag : 1;
>>unsigned tm_clone_flag : 1;
>>unsigned versioned_function : 1;
>> -  /* No bits left.  */
>> +
>> +  unsigned operator_delete_flag : 1;
>> +  /* 31 bits left.  */
>>  };
>
>
> that's unpleasant.  We have DECL_IS_{MALLOC,OPERATOR_{NEW,DELETE}} flags,
> which are all mutually exclusive.  If only there was a way to encode a
> 4-valued enumeration in fewer than 3 bits ... :)  (not sure why we don't
> have DECL_IS_FREE, and as we don't, why is DECL_IS_OPERATOR_DELETE needed?
>
> (we also have DECL_IS_{CON,DE}STRUCTOR flags, which I think are also
> mutually exclusive with the above.  So that's 5 or (6 if we add
> DECL_IS_FREE), that could be encoded in 3 bits.
>
> There may be even more mutually exclusive flags,
> DECL_STATIC_{CON,DE}STRUCTOR may be candiates?

Yes, there's room for cleanup (as I noted).  And ok, if we don't want
to regress 32bit hosts we can put
a new flag in decl_common indeed.

So please do that.

Anything else can be done as followup and need not be done as part of
this patch.  An enum for
this would work I guess.

Richard.

>
> nathan
>
> --
> Nathan Sidwell

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Nathan Sidwell]

On 11/21/2017 06:14 AM, Dominik Inführ wrote:

Hi,

this patch tries to extend tree-ssa-dce.c to remove unnecessary 
new/delete-pairs (it already does that for malloc/free). Clang does it too and 
it seems to be allowed by 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html. I’ve 
bootstrapped/regtested on aarch64-linux and x86_64-linux.


nice.


--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1787,7 +1787,9 @@ struct GTY(()) tree_function_decl {
   unsigned has_debug_args_flag : 1;
   unsigned tm_clone_flag : 1;
   unsigned versioned_function : 1;
-  /* No bits left.  */
+
+  unsigned operator_delete_flag : 1;
+  /* 31 bits left.  */
 };


that's unpleasant.  We have DECL_IS_{MALLOC,OPERATOR_{NEW,DELETE}} 
flags, which are all mutually exclusive.  If only there was a way to 
encode a 4-valued enumeration in fewer than 3 bits ... :)  (not sure why 
we don't have DECL_IS_FREE, and as we don't, why is 
DECL_IS_OPERATOR_DELETE needed?


(we also have DECL_IS_{CON,DE}STRUCTOR flags, which I think are also 
mutually exclusive with the above.  So that's 5 or (6 if we add 
DECL_IS_FREE), that could be encoded in 3 bits.


There may be even more mutually exclusive flags, 
DECL_STATIC_{CON,DE}STRUCTOR may be candiates?



nathan

--
Nathan Sidwell

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Jakub Jelinek]

On Wed, Nov 22, 2017 at 10:30:29AM +0100, Richard Biener wrote:
> --- a/gcc/tree-core.h
> +++ b/gcc/tree-core.h
> @@ -1787,7 +1787,9 @@ struct GTY(()) tree_function_decl {
>unsigned has_debug_args_flag : 1;
>unsigned tm_clone_flag : 1;
>unsigned versioned_function : 1;
> -  /* No bits left.  */
> +
> +  unsigned operator_delete_flag : 1;
> +  /* 31 bits left.  */
> 
> while it looks bad reality is that on 64bit pointer hosts we had 32 bits left.

But we can just add it to say tree_decl_common which has 14 spare bits or
tree_decl_with_vis which has another 14 spare bits.  By just noting the flag
applies only to FUNCTION_DECLs and enforcing it in the tree.h macros,
it will be easy to reuse that bit for something different for trees other
than FUNCTION_DECL.

Jakub

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Martin Jambor]

On Tue, Nov 21 2017, Jeff Law wrote:
> On 11/21/2017 04:14 AM, Dominik Inführ wrote:
>> Hi,
>> 
>> this patch tries to extend tree-ssa-dce.c to remove unnecessary 
>> new/delete-pairs (it already does that for malloc/free). Clang does it too 
>> and it seems to be allowed by 
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html. I’ve 
>> bootstrapped/regtested on aarch64-linux and x86_64-linux.
> Just a note, we've transitioned into stage3 in preparation for the
> upcoming gcc-8 release in the spring.  During stage3 we're addressing
> bugfixes, not further enhancements (with the exception of enhancements
> that were posted prior to stage1 close).
>
> So it's unlikely anyone will dig into this right now, unless there's an
> existing bugzilla around this missed optimization.

Unless I am mistaken, I think it is PR 23383

Martin

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Richard Biener]

On Tue, Nov 21, 2017 at 12:14 PM, Dominik Inführ
 wrote:
> Hi,
>
> this patch tries to extend tree-ssa-dce.c to remove unnecessary 
> new/delete-pairs (it already does that for malloc/free). Clang does it too 
> and it seems to be allowed by 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html. I’ve 
> bootstrapped/regtested on aarch64-linux and x86_64-linux.

Few comments.

+/* Return true when STMT is operator new call.  */
+
+bool
+gimple_call_operator_new_p (const gimple *stmt)
+{
+  tree fndecl;
+
+  if (is_gimple_call (stmt)
+  && (fndecl = gimple_call_fndecl (stmt)) != NULL_TREE)
+return DECL_IS_OPERATOR_NEW (fndecl);
+  return false;

make these take a gcall * please and drop the is_gimple_call check.

diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index aa54221253c..9a406c5d86c 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1787,7 +1787,9 @@ struct GTY(()) tree_function_decl {
   unsigned has_debug_args_flag : 1;
   unsigned tm_clone_flag : 1;
   unsigned versioned_function : 1;
-  /* No bits left.  */
+
+  unsigned operator_delete_flag : 1;
+  /* 31 bits left.  */

while it looks bad reality is that on 64bit pointer hosts we had 32 bits left.

Note that we could really pack things better and even make function_decl
smaller by using the tail-padding (for 64bit pointer hosts...) in
tree_decl_with_vis
which also has 32 + 14 bits left.

+ /* For operator delete [] we need to keep size operand
+alive. Otherwise this operand isn't available anymore
+when we finally decide that this stmt is necessary in
+   eliminate_unnecessary_stmts. If it should really be
+   unnecessary, a later pass can clean this up.  */
+ if (gimple_call_operator_delete_p (stmt))
+   {
+ for (unsigned i=1; i < gimple_call_num_args
(stmt); ++i)
+   {
+ tree arg = gimple_call_arg (stmt, i);
+ if (TREE_CODE (arg) == SSA_NAME)
+   mark_operand_necessary (arg);
+   }
+   }

bah ... so the "hack" for malloc/free pair removal doesn't really work very well
for new/delete.  What you do looks reasonable but in the end we might support
sth like "tentatively not necessary" and a late marking things necessary that
have been proven to be necessary anyway.

diff --git a/libstdc++-v3/testsuite/ext/bitmap_allocator/check_delete.cc
b/libstdc++-v3/testsuite/ext/bitmap_allocator/check_delete.cc
index bc36ed595e0..10e26615fb7 100644
--- a/libstdc++-v3/testsuite/ext/bitmap_allocator/check_delete.cc
+++ b/libstdc++-v3/testsuite/ext/bitmap_allocator/check_delete.cc
@@ -15,6 +15,8 @@
 // with this library; see the file COPYING3.  If not see
 // .

+// { dg-options "-fno-tree-dce" }
+
 // 20.4.1.1 allocator members

hmm.  I think it would be better to add a new C++ FE option
-fno-allocation-dce that
simply doesn't set DECL_IS_OPERATOR_{NEW,DELETE} similar to how we have
-fno-lifetime-dse?  There might be projects that are not happy with this DCE and
disabling _all_ DCE just to keep existing behavior looks bad.

Otherwise the patch looks straight-forward in case C++ folks are happy with it.

Thanks for working on this!  I think that if you manage to convince C++ folks
and fix the -fno-allocation-dce missing then I'd like to have this in
early stage3.
We've been requesting this for a long time.

Richard.


> Best,
> Dominik
>

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Jeff Law]

On 11/21/2017 10:30 AM, Dominik Inführ wrote:
> Thanks for the reply, I know that it’s too late for GCC 8. I wanted to get 
> some feedback on this patch, so I could address all issues until GCC 9 
> development starts. But I suppose it is better to just post it again later.
The problem is most folks' attention will be on bugfixing for the next
few months.

I did quickly scan the patch and didn't see anything terribly concerning
other than extending the one structure which folks will want to look at
more closely.  We always look closely at extending any core data
structures as that impacts memory usage.

I'll probably have to refer to the C++ experts on any specific language
issues that come into play when we open the trunk up again for new
development and come back to the patch.

Jeff

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Dominik Inführ]

Thanks for the reply, I know that it’s too late for GCC 8. I wanted to get some 
feedback on this patch, so I could address all issues until GCC 9 development 
starts. But I suppose it is better to just post it again later.

Dominik

> On 21 Nov 2017, at 18:09, Jeff Law  wrote:
> 
> On 11/21/2017 04:14 AM, Dominik Inführ wrote:
>> Hi,
>> 
>> this patch tries to extend tree-ssa-dce.c to remove unnecessary 
>> new/delete-pairs (it already does that for malloc/free). Clang does it too 
>> and it seems to be allowed by 
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html. I’ve 
>> bootstrapped/regtested on aarch64-linux and x86_64-linux.
> Just a note, we've transitioned into stage3 in preparation for the
> upcoming gcc-8 release in the spring.  During stage3 we're addressing
> bugfixes, not further enhancements (with the exception of enhancements
> that were posted prior to stage1 close).
> 
> So it's unlikely anyone will dig into this right now, unless there's an
> existing bugzilla around this missed optimization.
> 
> Just wanted to let you know where things stood so you don't interpret
> silence as "we don't care".
> 
> jeff



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [RFC][PATCH] Extend DCE to remove unnecessary new/delete-pairs

[Jeff Law]

On 11/21/2017 04:14 AM, Dominik Inführ wrote:
> Hi,
> 
> this patch tries to extend tree-ssa-dce.c to remove unnecessary 
> new/delete-pairs (it already does that for malloc/free). Clang does it too 
> and it seems to be allowed by 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html. I’ve 
> bootstrapped/regtested on aarch64-linux and x86_64-linux.
Just a note, we've transitioned into stage3 in preparation for the
upcoming gcc-8 release in the spring.  During stage3 we're addressing
bugfixes, not further enhancements (with the exception of enhancements
that were posted prior to stage1 close).

So it's unlikely anyone will dig into this right now, unless there's an
existing bugzilla around this missed optimization.

Just wanted to let you know where things stood so you don't interpret
silence as "we don't care".

jeff