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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> Note the GIMPLE we expand from looks weird:
> 
> struct GoodIterD.2094 operator+ (intD.9 D.2129, struct GoodIterD.2094 &
> restrict D.2130)
> {
>   <bb 2> [local count: 10000]:
>   *_2(D) = operator- (_3(D), _4(D)); [return slot optimization] [tail call]
>   return _2(D);
> 
> somehow the inlined(?) thunk has some indirection exposed and the RSO
> looks misplaced.

How else we can express calls returning through hidden reference at GIMPLE?
I believe the above is effectively telling that the thunk should pass _2(D) as
the hidden return slot pointer.

If I use
struct S { S (); S (const S &); };
int baz (int);

S
foo ()
{
  baz (baz (baz (baz (baz (0)))));
  baz (baz (baz (baz (baz (1)))));
  baz (baz (baz (baz (baz (2)))));
  baz (baz (baz (baz (baz (3)))));
  baz (baz (baz (baz (baz (4)))));
  baz (baz (baz (baz (baz (5)))));
  baz (baz (baz (baz (baz (6)))));
  baz (baz (baz (baz (baz (7)))));
  baz (baz (baz (baz (baz (8)))));
  baz (baz (baz (baz (baz (9)))));
  return S ();
}

S
bar ()
{
  baz (baz (baz (baz (baz (0)))));
  baz (baz (baz (baz (baz (1)))));
  baz (baz (baz (baz (baz (2)))));
  baz (baz (baz (baz (baz (3)))));
  baz (baz (baz (baz (baz (4)))));
  baz (baz (baz (baz (baz (5)))));
  baz (baz (baz (baz (baz (6)))));
  baz (baz (baz (baz (baz (7)))));
  baz (baz (baz (baz (baz (8)))));
  baz (baz (baz (baz (baz (9)))));
  return S ();
}

instead such that it is at -O2 ipa-icf optimized and is not inlined back, then
that
struct S bar ()
{
  <bb 2> [local count: 1073741824]:
  *_2(D) = foo (); [return slot optimization] [tail call]
  return _2(D);

}
appears in *.optimized dump, yet we apparently don't tail call optimize it even
when we should:
_Z3barv:
.LFB3:
        .cfi_startproc
        pushq   %r12
        .cfi_def_cfa_offset 16
        .cfi_offset 12, -16
        movq    %rdi, %r12
        call    _Z3foov
        movq    %r12, %rax
        popq    %r12
        .cfi_def_cfa_offset 8
        ret
        .cfi_endproc
.LFE3:
        .size   _Z3barv, .-_Z3barv
For -O0, perhaps IPA-ICF should be really disabled if !optimize no matter what
the user said, as we e.g. can't really expect any attempts on emitting the tail
calls in that case.  But it wouldn't hurt to fix expansion so that it doesn't
ICE on it too.

Reply via email to