[Bug tree-optimization/94294] New: [missed optimization] new+delete of unused local string not removed

[Bug tree-optimization/94294] New: [missed optimization] new+delete of unused local string not removed

[eyalroz at technion dot ac.il]

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

            Bug ID: 94294
           Summary: [missed optimization] new+delete of unused local
                    string not removed
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eyalroz at technion dot ac.il
  Target Milestone: ---

(Relevant Godbolt: https://godbolt.org/z/GygbjZ)

This is the second of two apparent bugs, following bug 94293. They both
manifest when compiling the following program:

#include <string>

int bar() {
    struct poor_mans_pair {
        int first;
        std::string second;
    };
    poor_mans_pair p { 
        123, "Hey... no small-string optimization for me please!" };
    return p.first;
}

For x86_64, this would ideally compile into:

bar():
        mov     eax, 123
        ret

but when compiling this  with GCC 10.0.1 20200322 (or GCC 9.x etc.), we get
assembly which calls operator new[](), populates the string, calls operator
delete[](), then returns 123:

bar():
        sub     rsp, 8
        mov     edi, 51
        call    operator new(unsigned long)
        movdqa  xmm0, XMMWORD PTR .LC0[rip]
        mov     esi, 51
        mov     rdi, rax
        movups  XMMWORD PTR [rax], xmm0
        movdqa  xmm0, XMMWORD PTR .LC1[rip]
        movups  XMMWORD PTR [rax+16], xmm0
        movdqa  xmm0, XMMWORD PTR .LC2[rip]
        movups  XMMWORD PTR [rax+32], xmm0
        mov     eax, 8549
        mov     WORD PTR [rdi+48], ax
        mov     BYTE PTR [rdi+50], 0
        call    operator delete(void*, unsigned long)
        mov     eax, 123
        add     rsp, 8
        ret
.LC0:
        .quad   7935393319309894984
        .quad   3273110194895396975
.LC1:
        .quad   8007513861377913971
        .quad   8386118574366356592
.LC2:
        .quad   2338053640980164457
        .quad   8314037903514690925

This bug report is about how the allocation and de-allocation are not
elided/optimized-away, even though the std::string variable is local and
unused.

AFAICT, g++ is not required to do this. And, in fact, clang++ doesn't do this
with its libc++. cppreference says that, starting in C++14,

> New-expressions are allowed to elide or combine allocations made 
> through replaceable allocation functions. In case of elision, the
> storage may be provided by the compiler without making the call to 
> an allocation function (this also permits optimizing out unused
> new-expression)

and this is, indeed, the case of an unused new-expression. Well,
eventually-unused. 

Note: I suppose it's theoretically possible that this bug only manifests
because   bug 94293 prevents the allocated space from being recognized as
unused; but I can't tell whether that's the case.

[Bug tree-optimization/94294] [missed optimization] new+delete of unused local string not removed

[eyalroz at technion dot ac.il]

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

--- Comment #1 from Eyal Rozenberg <eyalroz at technion dot ac.il> ---
Note:

The bugs also manifest with this simpler program:


#include <string>

int bar() {
    std::string second { "Hey... no small-string optimization for me please!"
};
    return 123;
}

See: https://godbolt.org/z/LjmNYi

[Bug tree-optimization/94294] [missed optimization] new+delete of unused local string not removed

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Eyal Rozenberg from comment #0)
> Note: I suppose it's theoretically possible that this bug only manifests
> because   bug 94293 prevents the allocated space from being recognized as
> unused; but I can't tell whether that's the case.

Pretty sure that's the case, gcc removes new/delete pairs now when nothing
writes to that memory.

[Bug tree-optimization/94294] [missed optimization] new+delete of unused local string not removed

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-03-24
           Keywords|                            |missed-optimization
         Depends on|                            |94293
                 CC|                            |rguenth at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
See PR94293 for more analysis.  We can use PR94294 for the new/delete issue and
the other for the DSE one.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293
[Bug 94293] [missed optimization] Useless statements populating local string
not removed

[Bug tree-optimization/94294] [missed optimization] new+delete of unused local string not removed

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
I don't believe there is a "new/delete" issue.

[Bug tree-optimization/94294] [missed optimization] new+delete of unused local string not removed

[tnfchris at gcc dot gnu.org]

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

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tnfchris at gcc dot gnu.org

--- Comment #5 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #4)
> I don't believe there is a "new/delete" issue.

I wonder.. , looking at

#include <cstdint>
#include <cstdlib>
#include <vector>

struct param {
  uint32_t k;
  std::vector<uint8_t> src;
  std::vector<uint8_t> ref0;
};

size_t foo() {
    param test[] = {
    {48, {255, 0, 0, 0, 0, 0}
    }};
    return sizeof(test);
}

I had expected the answer to simply be

        mov     w0, #56
        ret

since the new and delete can be elided.
...but GCC generates some pretty bad code here... 
https://godbolt.org/z/EPoYYohPa

In this case nothing of the structure is used at all yet we keep all the
construction code.