Re: [c++] Remove iffy uses of DECL_INLINE

[Jan Hubicka <hubicka at ucw dot cz>]

> Jan Hubicka wrote:
> 
> I like this patch overall.  I agree that the C++ front end has no 
> business setting DECL_INLINE.  (Setting DECL_DECLARED_INLINE_P is of 
> course its job, though.)  I'll approve the removal of inline_conversion 
> at this point.
> 
> >        /* Don't complain if we abort or throw.  */
> >        && !current_function_returns_abnormally
> >        && !DECL_NAME (DECL_RESULT (fndecl))
> >!       /* Normally, with -Wreturn-type, SSA pass will complain.  Warn
> >!          for all functions that might be optimized out as unreachable
> >!          and never compiled.  */
> >!       && (!TREE_PUBLIC (fndecl) || processing_template_decl)
> >        /* Structor return values (if any) are set by the compiler.  */
> >        && !DECL_CONSTRUCTOR_P (fndecl)
> >        && !DECL_DESTRUCTOR_P (fndecl))
> 
> It would be good if we could mark the function in some way so that SSA 
> doesn't warn again if we do compile the function, but that's orthogonal 
> to this patch.

C frontend does TREE_NO_WARNING (fndecl) = 1;, I will add the code there
too.
> 
> I'm a little worried that because of the more generous definition of 
> possibly_inlined_p we'll synthesize more methods and such and thus slow 
> down the compiler.  Have you looked at compile-time or memory impact on, 
> say, libstdc++ compilation?

I tested Gerald's testcase and saw no differences.
I've put it into separate predicate precisely because I tought it might
cause problems later and thus if see this is important factor, we can
try to come up with some heuristics.  However ....
> 
> For example, this code in mark_used:
> 
> ! 		   && possibly_inlined_p
> ! 		       (DECL_TEMPLATE_RESULT (
> ! 		         template_for_substitution (decl))))
> 
> means that when optimizing we might instantiate every template function 
> that has been called if there is a definition available, even if that 
> function is an extern template (i.e., marked as explicitly instantiated 
> elsewhere).

For IPA optimization I think that this is quite important however.  We
should be able to inline the functions and also be able to analyze the
semantics.  We don't do the second very well, sicne they end up being
OVERWRITTABLE in cgraph's visibility class.  I am thinking about
including OVERWRITTABLE_ONE_DECL that would mean that one can analyze
the function but not modify it in a incompatible way. (so constant
propagation/alias analysis and such we see through, but we won't alter
the API or datastruture it touch).
This is why I didn't even tried to put more effort into deciding whether
the function is good inline candidate or not (that we can't do very weel
at this point anyway)

Honza
> 
> Thoughts?
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713