Re: Remove some curious inline modifiers

[Jim Wilson <wilson at specifixinc dot com>]

Jan Hubicka wrote:
> 2004-01-03  Jan Hubicka  <jh@suse.cz>
> 	* c-pretty-print.c (pp_c_type_cast, pp_c_abstract_declarator,
> 	pp_c_character_constant, pp_c_floating_constant,
> 	pp_c_additive_expression, pp_c_shift_expression,
> 	pp_c_equality_expression, pp_c_and_expression,
> 	pp_c_exclusive_or_expression, pp_c_inclusive_or_expression,
> 	pp_c_logical_and_expression): Remove inline modifier.
> 	* dwarf2out.c (get_AT): Likewise.
> 	* et-forest.c (et_splay): Likewise.
>
> 	* mangle.c (write_mangled_name): Remove inline modifier.

This patch modifies haifa-sched.c and ra.h, but these are not mentioned 
in the ChangeLog entry.

You said the c-pretty-print.c functions are recursive, but looking at 
them, the first 4 functions are not recursive, and the 
pp_c_inclusive_or_expression function is not recursive.  It looks like 
you just dropped every use of inline without checking whether the 
function was recursive or not.

The dwarf2out.c change looks OK.

For et-forest.c, the problem is the function is to big for the default 
inlining limits, but some people change the inline limits, and whether 
we hit inline limits may be machine dependent.  It seems reasonable to 
me to drop the inline though to help get rid of a warning.

The haifa-sched functions are recursive, so that is OK, but this needs 
to be mentioned in the ChangeLog entry.

Not clear why the reason for the ra.h change, unless perhaps because the 
declarations don't match the definitions?  But in that case why not add 
the inline keyword to the definitions?  Maybe they are too big because 
obstack_alloc is a macro?  But that will be target dependent, because 
the macro you get depends on what compiler is being used to build gcc.

The cp/mangle patch seems to be the same issue as the et-forest.c change.

I have no particular attachment to the inline keywords.  However, I'm 
concerned here whether we can actually get rid of all of the -Winline 
warnings for all targets.  Different functions will be different sizes 
for different targets, this puts us in the position are needing to 
assume the worst case function sizes, which may hurt performance for 
targets that end up with small function sizes.  There may also be other 
issues, for instance, differences in ABIs or standard C header files may 
force some functions to be uninlinable for some targets but not others. 
   We either make the worst case assumptions which penalize some 
targets, or we live with some -Winline warnings.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com