public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/106991] New: new+delete pair not optimized by g++ at -O3 but optimized at -Os
@ 2022-09-21  4:53 hiraditya at msn dot com
  2022-09-21  8:17 ` [Bug ipa/106991] " rguenth at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: hiraditya at msn dot com @ 2022-09-21  4:53 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106991

            Bug ID: 106991
           Summary: new+delete pair not optimized by g++ at -O3 but
                    optimized at -Os
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hiraditya at msn dot com
  Target Milestone: ---

https://godbolt.org/z/PeYcoqTKn

-----------------------------------------------------------
#include<cassert>
#include<cstdlib>

int volatile gv = 0;

void* operator new(long unsigned sz ) {
    ++gv;
    return malloc( sz );
}

void operator delete(void *p) noexcept {
    --gv;
    free(p);
}

class c {
    int l;
    public:
        c() : l(0) {}
        int get(){ return l; }
};

int caller( void ){
    c *f = new c();
    assert( f->get() == 0 );
    delete f;
    return gv;
}
-----------------------------------------------------------

$ g++ -std=c++20 -O3

operator new(unsigned long):
        mov     eax, DWORD PTR gv[rip]
        add     eax, 1
        mov     DWORD PTR gv[rip], eax
        jmp     malloc
operator delete(void*):
        mov     eax, DWORD PTR gv[rip]
        sub     eax, 1
        mov     DWORD PTR gv[rip], eax
        jmp     free
caller():
        sub     rsp, 8
        mov     eax, DWORD PTR gv[rip]
        mov     edi, 4
        add     eax, 1
        mov     DWORD PTR gv[rip], eax
        call    malloc
        mov     esi, 4
        mov     rdi, rax
        call    operator delete(void*, unsigned long)
        mov     eax, DWORD PTR gv[rip]
        add     rsp, 8
        ret
gv:
        .zero   4
-----------------------------------------------------------
$ g++ -std=c++20 -Os

operator new(unsigned long):
        mov     eax, DWORD PTR gv[rip]
        inc     eax
        mov     DWORD PTR gv[rip], eax
        jmp     malloc
operator delete(void*):
        mov     eax, DWORD PTR gv[rip]
        dec     eax
        mov     DWORD PTR gv[rip], eax
        jmp     free
caller():
        mov     eax, DWORD PTR gv[rip]
        ret
gv:
        .zero   4

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug ipa/106991] new+delete pair not optimized by g++ at -O3 but optimized at -Os
  2022-09-21  4:53 [Bug c++/106991] New: new+delete pair not optimized by g++ at -O3 but optimized at -Os hiraditya at msn dot com
@ 2022-09-21  8:17 ` rguenth at gcc dot gnu.org
  2022-09-21 11:18 ` hubicka at ucw dot cz
  2022-09-21 21:37 ` hiraditya at msn dot com
  2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-09-21  8:17 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106991

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Keywords|                            |missed-optimization
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
   Last reconfirmed|                            |2022-09-21
          Component|tree-optimization           |ipa
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Looks like inlining decisions decide to inline new but not delete but for -Os
we inline none and elide the new/delete pair.

Maybe we can devise some inline hints to keep pairs?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug ipa/106991] new+delete pair not optimized by g++ at -O3 but optimized at -Os
  2022-09-21  4:53 [Bug c++/106991] New: new+delete pair not optimized by g++ at -O3 but optimized at -Os hiraditya at msn dot com
  2022-09-21  8:17 ` [Bug ipa/106991] " rguenth at gcc dot gnu.org
@ 2022-09-21 11:18 ` hubicka at ucw dot cz
  2022-09-21 21:37 ` hiraditya at msn dot com
  2 siblings, 0 replies; 4+ messages in thread
From: hubicka at ucw dot cz @ 2022-09-21 11:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106991

--- Comment #2 from Jan Hubicka <hubicka at ucw dot cz> ---
> Looks like inlining decisions decide to inline new but not delete but for -Os
> we inline none and elide the new/delete pair.
> 
> Maybe we can devise some inline hints to keep pairs?

Inliner is mostly built around an assumption that inline decisions are
idnependent on each call site.  It would be possible to add something
like that though: we could add links to inline summaries to hold the
pairs, modify can_inline and want_inline predicates to understand them
and extend inline_call to do both inlines when needed.  It will cause
some fallout since users of inline_call does not expect it to modify
other call sites.

I am not sure how good idea this would be though.  It seems to me that
it makes sense to treat them independently.

The reason we do not inline delete here is that delete used is different
form the one defined. Function calls
  operator delete(void*, unsigned long)
while testcase defines
  operator delete(void*)
Honza

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug ipa/106991] new+delete pair not optimized by g++ at -O3 but optimized at -Os
  2022-09-21  4:53 [Bug c++/106991] New: new+delete pair not optimized by g++ at -O3 but optimized at -Os hiraditya at msn dot com
  2022-09-21  8:17 ` [Bug ipa/106991] " rguenth at gcc dot gnu.org
  2022-09-21 11:18 ` hubicka at ucw dot cz
@ 2022-09-21 21:37 ` hiraditya at msn dot com
  2 siblings, 0 replies; 4+ messages in thread
From: hiraditya at msn dot com @ 2022-09-21 21:37 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106991

--- Comment #3 from AK <hiraditya at msn dot com> ---
Thanks for identifying the underlying issue @Jan 
After modifying the definition of operator delete. gcc does optimize it at -O3
as well.

https://godbolt.org/z/1WPqaWrEr

// source code
#include<cassert>
#include<cstdlib>

int volatile gv = 0;

void* operator new(long unsigned sz ) {
    ++gv;
    return malloc( sz );
}

void operator delete(void *p, unsigned long) noexcept {
    --gv;
    free(p);
}

class c {
    int l;
    public:
        c() : l(0) {}
        int get(){ return l; }
};

int caller( void ){
    c *f = new c();
    assert( f->get() == 0 );
    delete f;
    return gv;
}

$ $ g++ -std=c++20 -O3

```
operator new(unsigned long):
        mov     eax, DWORD PTR gv[rip]
        add     eax, 1
        mov     DWORD PTR gv[rip], eax
        jmp     malloc
operator delete(void*, unsigned long):
        mov     eax, DWORD PTR gv[rip]
        sub     eax, 1
        mov     DWORD PTR gv[rip], eax
        jmp     free
caller():
        mov     eax, DWORD PTR gv[rip]
        add     eax, 1
        mov     DWORD PTR gv[rip], eax
        mov     eax, DWORD PTR gv[rip]
        sub     eax, 1
        mov     DWORD PTR gv[rip], eax
        mov     eax, DWORD PTR gv[rip]
        ret
gv:
        .zero   4
```

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-09-21 21:37 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-21  4:53 [Bug c++/106991] New: new+delete pair not optimized by g++ at -O3 but optimized at -Os hiraditya at msn dot com
2022-09-21  8:17 ` [Bug ipa/106991] " rguenth at gcc dot gnu.org
2022-09-21 11:18 ` hubicka at ucw dot cz
2022-09-21 21:37 ` hiraditya at msn dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).