Consider the following code:
let[@inline] foo f x =
(f[@inlined]) x + 1
let bar x =
let[@inline] aux y = y + 1 in
(foo[@inlined]) aux x
Trying to compile it with a max_inlining_depth of 1 results in the following warnings:
File "/home/guigui/tmp/warn.ml", line 3, characters 2-17:
3 | (f[@inlined]) x + 1
^^^^^^^^^^^^^^^
Warning 55: Cannot inline: [@inlined] attribute was not used on this function application (the optimizer did not know what function was being applied)
File "/home/guigui/tmp/warn.ml", line 7, characters 2-23:
7 | (foo[@inlined]) aux x
^^^^^^^^^^^^^^^^^^^^^
Warning 55: Cannot inline: [@inlined] attribute was not used on this function application{Do_not_inline}
Whereas the first warning is correct (an indirect and unknown call cannot be inlined), the second warning is much more puzzling and misleading: indeed, the foo function has been inlined (as can be seen by looking at the -dflambda output or the inlining report), and it is in fact the call to f inside the body of the inlined foo which was not inlined, because of the maximum inlining depth.
There are two things that should probably be fixed in that situation:
- the location of the warning (particularly now that there is source code quoting in the error message)
- the contents of the warning message should be clearer about why the inlining did not take place (the message is generated there :
|
| Do_not_inline -> |
|
(* emission of the warning at this point should not happen, |
|
if it does, then that means that |
|
{Inlining_decision.make_decision_for_call_site} |
|
did not honour the attributes on the call site *) |
|
if not (DA.do_not_rebuild_terms dacc) then begin |
|
warn_not_inlined_if_needed apply |
|
"[@inlined] attribute was not used on this function application\ |
|
{Do_not_inline}" |
|
end; |
)
Consider the following code:
Trying to compile it with a max_inlining_depth of 1 results in the following warnings:
Whereas the first warning is correct (an indirect and unknown call cannot be inlined), the second warning is much more puzzling and misleading: indeed, the
foofunction has been inlined (as can be seen by looking at the-dflambdaoutput or the inlining report), and it is in fact the call tofinside the body of the inlinedfoowhich was not inlined, because of the maximum inlining depth.There are two things that should probably be fixed in that situation:
ocaml/middle_end/flambda/simplify/simplify_apply_expr.ml
Lines 132 to 141 in f7d8fcc