> > If it is in ipa_fn_summary, where would I do the lookup_attribute? It is constructed in ipa-fnsummary.cc:analyze_function and then needs to be duplicated by the duplicate hooks > > Anyway, looking at the spots where I've used DECL_OPTIMIZABLE_INLINE_P > (agree it is a bad name), I think tree_inlinable_function_p > and expand_call_inline don't have access to it (so would need to > lookup_attribute it), devirtualization_time_bonus does, > estimate_size_and_time too, ipa-icf.cc doesn't (I think), ipa-inline.cc > does though I think the code will be less readable when using those, > ipa-split.cc I doubt it has them. > So, I think it would be easier to keep it at least for now as a flag > in function_decl and perhaps add a comment that if we run out of bits, > this one could be changed into ipa_fn_summary + some lookup_attributes.
Concerning the other uses outside of inliner: - tree_inlinable_function_p and expand_call_inline check it to warn. We could silence the wraning via NO_INLINE_WRANING flag. - ipa-icf only wants to be sure that both functions are same. It will compare attribute lists, so it will likely bail out on the new attribute differences. - ipa-split indeed would need to check it. Thinking of it, extra flag in DECL is probably slightly easier to use, so the IPA changes are OK as they are... > > And DECL_AGGRESSIVE_INLINING_P looks reasonable. ... perhaps with this change - I think it represents the intended use more clearly. Honza > > Jakub >
