Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add compiler annotation to check that a function has no free variables #6682

Closed
vicuna opened this issue Nov 28, 2014 · 5 comments
Closed

add compiler annotation to check that a function has no free variables #6682

vicuna opened this issue Nov 28, 2014 · 5 comments

Comments

@vicuna
Copy link

vicuna commented Nov 28, 2014

Original bug ID: 6682
Reporter: milanst
Status: acknowledged (set by @gasche on 2014-12-16T07:42:01Z)
Resolution: open
Priority: high
Severity: feature
Category: language features
Monitored by: @diml

Bug description

When writing performance sensitive code it is often necessary to make sure that no closures are allocated for helper functions. It would nice if compiler could warn the programmer in cases where some free variable is accidentally introduced.
For example:
let helper_function [@ closed] arg1 arg2 = ....

then compiler can warn me if helper function has free variables which would cause closure allocation and probably prevent some optimizations.

[@ closed] is probably not the best name, hopefully we can come up with better name.

Also, it would be marginally better if I could put annotation between let and function name but that is not valid syntax.

@vicuna
Copy link
Author

vicuna commented Nov 28, 2014

Comment author: @gasche

That looks like an excellent candidate for an external preprocessing analysis: it does not depend much on compiler analyses (contrarily to, say, tail-callness) and seems easy to check purely syntactically.

@vicuna
Copy link
Author

vicuna commented Nov 28, 2014

Comment author: milanst

What about the case where function close over some global value from some different module that is opened?
In that case closure is not allocated (I think).
Would parse tree contain enough information to figure that out?

@vicuna
Copy link
Author

vicuna commented Nov 28, 2014

Comment author: @gasche

Indeed, this case is harder to do from an external tool -- it can be done by inspecting¹ the .cmx (not unreasonable), but you need to rebuild the path-handling logic from the compiler to know where those are. I think it would be useful to be able to do that conveniently in an external tool, because that's a building block that other tools would need, but I'm not sure how much work that is, so I'll just withdraw my remark for now.

¹: the "cmx" has "value approximations" for globals on which it knows something; in the case of Value_closure, the first argument is a Clambda.function_description record with a (fun_closed : bool) field with the desired information. "ocamlobjinfo foo.cmx" prints it.

@vicuna
Copy link
Author

vicuna commented Dec 8, 2016

Comment author: @mshinwell

I think this kind of thing would need to be checked at the end of Flambda.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant