This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/54770] sibling call optimization is not applied where it ought to be


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54770

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

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-02 12:52:39 UTC ---
It is not tail call optimized (unless -std=c++11, which generates different
code and is tail call optimized btw), because points-to analysis thinks that
the this->H call in MainNode::H may use the tmp variable:
  # .MEM_25 = PHI <.MEM_27(6), .MEM_30(4)>
  # PT = nonlocal escaped
  # prephitmp_29 = PHI <pretmp_31(6), &MEM[(voidD.45 *)&_ZTV8MainNodeD.2389 +
16B](4)>
<L6>:
  # .MEM_11 = VDEF <.MEM_25>
  tmpD.2422 ={v} {CLOBBER};
  # VUSE <.MEM_11>
  # PT = nonlocal escaped
  _13 = MEM[(intD.9 (*__vtbl_ptr_typeD.2134) () *)prephitmp_29 + 16B];
  # .MEM_14 = VDEF <.MEM_11>
  # USE = nonlocal null { D.2320 D.2389 D.2422 } (glob)
  # CLB = nonlocal null { D.2320 D.2389 D.2422 } (glob)
  OBJ_TYPE_REF(_13;this_3(D)->2) (this_3(D));
  # VUSE <.MEM_14>
  return;

It is true that tmpD.2422 is addressable:
;;    pred:       2 (EH,EXECUTABLE)
<L4>: [LP 1]
  [MNT 5] # .MEM_15 = VDEF <.MEM_8>
  # USE = nonlocal null { D.2320 D.2389 D.2422 } (glob)
  # CLB = nonlocal null { D.2320 D.2389 D.2422 } (glob)
  _ZN9IntrusiveI4NodeED1EvD.2361 (&tmpD.2422);
  resx 2
;;    succ:
but here it is dominated by a clobber stmt for that variable.  I wonder if PTA
could be thought something about TREE_CLOBBER_Ps, the question is what exactly.
Here the call is dominated by the clobber stmt and there is no stmt mentioning
that var in any way in between the clobber and the call.  Only saying that a
var can't escape to calls dominated by a clobber stmt wouldn't be enough, if
e.g. a loop is unrolled, we could have
  bar ();
  foo (&tmp);
  bar ();
  tmp ={v} {CLOBBER};
  bar ();
  foo (&tmp);
  bar ();
  tmp ={v} {CLOBBER};
While it is ok to assume (I think) that tmp can't be used in the 3rd bar call,
in the 4th bar call it can be used.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]