This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/54770] sibling call optimization is not applied where it ought to be
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 02 Oct 2012 12:52:39 +0000
- Subject: [Bug c++/54770] sibling call optimization is not applied where it ought to be
- Auto-submitted: auto-generated
- References: <bug-54770-4@http.gcc.gnu.org/bugzilla/>
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.