Henrik Mannerström <henrik.mannerstrom@xxxxxxxxx> writes: > Ian Lance Taylor wrote: >>> I get the following warning from the compiler: >>> >>> header.h:10: warning: inlining failed in call to ‘double hill(double, >>> double, double)’: call is unlikely and code size would grow >>> >>> I know that the "--param" option has many variables controlling inlining >>> but I don't know which ones to change. Can I get some kind of diagnostic >>> of the specific decision the compiler makes when not inlining? >> To my eyes, that is the diagnostic right there: "the call is unlikely >> and code size would grow." What kind of diagnostic are you looking for? > I tried the following: > > -finline-limit=100000 --param large-function-growth=100000 --param > inline-unit-growth=100000 , > > but the messages did not go away. I have organized my code in small > functions but I wish the compiler would flatten most of it to avoid > function call overhead (when it is reasonable). The function in question > is called in three places from a function that is called only from one > place, inside a function that is called in two main loops. I hoped the > compiler might be able to tell me something like "inlining function X > would result in code growth Y%, which is prohibited by parameter Z". I see. A call that is unlikely and would cause code size to grow is never a good choice for inlining. Adjusting parameters isn't going to change that. You may want to look at the always_inline and flatten function attributes. Ian
