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]

Re: c++/1687: Extreme compile time regression from 2.95.2


On Tue, Feb 06, 2001 at 12:57:26PM -0500, Kelley Cook wrote:
> I don't see a way to add onto the GNATs item I opened, so I shall just 
> post it here and hope someone with access can add onto PR c++/1687

You do it by cc:ing gcc-gnats and leaving the bug tag in the subject
line.  Also note bug discussion belongs on gcc-bugs, not gcc-patches.

> The geometric regression that occurs only happens when "-finline" is 
> enabled (which happens with -O1)

This is the same sort of problem as the last time you had trouble with
this test case, but in a different place.  -O1 with a 16-input mux():

 68.47     40.14    40.14        54   743.33  1082.78  walk_tree
 16.09     49.57     9.43 236756969     0.00     0.00  expand_call_inline
  7.93     54.22     4.65 143489477     0.00     0.00  statement_code_p
  4.67     56.96     2.74 143489445     0.00     0.00  cp_statement_code_p
  2.58     58.47     1.51  71745291     0.00     0.00  first_rtl_op

We've got the messy tree structure, with tons of pointers to the same
few nodes, same as last time.  We're trying to walk over it, again,
and visiting the same few nodes over and over, again.  It's just
happening in a different place.  walk_tree(expand_call_inline) is
responsible for finding call sites and expanding them inline, should
this be feasible.  There are no call sites in your test function, but
it doesn't know that and it's got to grovel through 236,756,969 tree
nodes to find out.

I am not sure what to do about this.  Unlike in RTL, there is no handy tag
on the statement nodes to indicate "this one performs a function call."
(Perhaps there should be.)  So using walk_stmt_tree is not practical.  Also
there are strange things going on with TARGET_EXPRs which I do not
understand.  We could go for walk_tree_without_duplicates, but not fully
understanding the logic here I am not confident that would work. Maybe a
walk_expr_tree that doesn't visit type and decl nodes would be enough of a
performance improvement?

zw

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