Conversation
| [(fun_id, Lfunction{kind; params; body = create_wrapper_body wrapper_body; | ||
| attr; loc}); inner] | ||
| let body, inner = aux [] body in | ||
| let attr = default_stub_attribute in |
There was a problem hiding this comment.
Is it possible that in the future there may be attributes that we don't want to discard when marking something as a stub? I wonder if it would be better if there was a function set_stub_attribute or something.
There was a problem hiding this comment.
It's not really discarding them, it's just not duplicating them onto the wrapper. Attributes which should appear on both the wrapper and the function seem less likely to me (there are none at the moment), so I think starting from default_stub_attribute and explicitly copying any that it should share would be more natural (which is what the current code does except that at the moment there are none to explicitly share).
|
I reviewed it too, seems ok and get rid of an ugly hack. I approve too. |
Add stub marker to lambda code
When Flambda has to create small functions for things like partial applications, it marks these functions as "stub" functions. This changes the heuristics for inlining them, and can produce much better code.
However, lambda also creates such functions and they are not currently marked as "stub" since lambda code has no such notion. This PR fixes that deficiency. It adds a
stubfield to thefunction_attributetype inlambda.mland uses it to mark the small wrapper functions produced by lambda.closure.mlis also updated to always inline such functions much as flambda does -- although since they're all tiny this change is basically a no-op.The addition of "stub" to lambda also allows to remove a horrible hack around the treatment of "default argument wrappers" in
closure_conversion.ml.The following program demonstrates the benefit of this PR. It produces much better code with this change, as without it the partial applications of labelled functions get in the way of the inlining heuristics: