User account creation filtered due to spam.

Bug 40223 - cgraph_estimate_size_after_inlining missmatch
Summary: cgraph_estimate_size_after_inlining missmatch
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2009-05-22 14:46 UTC by Sergei Larin
Modified: 2009-06-08 15:54 UTC (History)
3 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Sergei Larin 2009-05-22 14:46:28 UTC
It is not so much a bug report, but probably a note:

In ipa-inline.c function cgraph_estimate_size_after_inlining has the following loop:

  for (arg = DECL_ARGUMENTS (fndecl); arg; arg = TREE_CHAIN (arg))
    call_insns += estimate_move_cost (TREE_TYPE (arg));

Should it actually be something like this: 

  for (arg = DECL_ARGUMENTS (fndecl); arg; arg = TREE_CHAIN (arg))
   if (!VOID_TYPE_P (TREE_TYPE (arg)))
    call_insns += estimate_move_cost (TREE_TYPE (arg));

fndecl usually has VOID as last tree chain member, and that adds 4 points to cost that it is probably not intending. 
See tree-inline.c on trunk (147575)estimate_num_insns:

        /* Our cost must be kept in sync with
	   cgraph_estimate_size_after_inlining that does use function
	   declaration to figure out the arguments.  */
	if (decl && DECL_ARGUMENTS (decl))
	    tree arg;
	    for (arg = DECL_ARGUMENTS (decl); arg; arg = TREE_CHAIN (arg))
	      if (!VOID_TYPE_P (TREE_TYPE (arg)))
	        cost += estimate_move_cost (TREE_TYPE (arg));

  My code did trigger gcc_assert (size >= 0); in cgraph_estimate_size_after_inlining which I believe might be related to the above described.
Comment 1 Richard Biener 2009-05-22 18:23:10 UTC
Comment 2 Jan Hubicka 2009-06-08 15:54:00 UTC
The loops should be in sync, but I am but confused here.

I originally added the code only when walking types, not actual declarations, since in decls we don't use that VOIDtype terminator.  There was some side case where declaration actually had VOID argument in C++, but I don't recall the exact scenario.

There is gcc_assert (!VOID_TYPE_P (type)) in estimate_move_cost I would expect to fire if we was ever compiling function having VOID in the parm list.

How did you fire the >= 0 assert?