[Bug c++/110648] New: Missed optimization for small returned optional leads to redundant memory accesses

["cfsteefel at arista dot com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 110648
           Summary: Missed optimization for small returned optional leads
                    to redundant memory accesses
           Product: gcc
           Version: 11.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cfsteefel at arista dot com
  Target Milestone: ---

The following code 

#include <optional>

std::optional< int >
foo( int x ) {
    return 1;
}

produces x86_64 assembly which does two stores into the stack, and then a load
into rax, rather than simply operating directly on rax.

i.e.:
foo(int):
        mov     DWORD PTR [rsp-8], 1
        mov     BYTE PTR [rsp-4], 1
        mov     rax, QWORD PTR [rsp-8]
        ret

clang produces much more direct code:
foo(int):                                # @foo(int)
        movabs  rax, 4294967297
        ret

Since the returned value is always returned in rax as the optional is small
enough (less than two registers wide), there is no reason for the memory
accesses here.

The code can be improved by naming the returned object, but this breaks down
again if there are any conditionals, i.e.:
std::optional< int >
foo( int x ) {
    std::optional< int > ret = 1;
    return ret;
}

produces better code, but there is no way to get this better code once a branch
is introduced, i.e.

std::optional< int >
foo( int x ) {
    std::optional< int > ret = 1;
    if ( x < 1 ) {
      return std::nullopt;
    }
    return ret;
}

The same applies with godbolts' trunk version of gcc, as well as gcc11.3.