Skip to content

Limit the number of parameters for an uncurried or untupled function#9620

Merged
xavierleroy merged 3 commits intoocaml:trunkfrom
xavierleroy:limited-uncurrying
Jun 5, 2020
Merged

Limit the number of parameters for an uncurried or untupled function#9620
xavierleroy merged 3 commits intoocaml:trunkfrom
xavierleroy:limited-uncurrying

Conversation

@xavierleroy
Copy link
Copy Markdown
Contributor

This commit introduces a quantity Lambda.max_arity that is the maximal number of parameters that a Lambda function can have.

Uncurrying is throttled so that, for example, assuming the limit is 10, a 15-argument curried function fun x1 ... x15 -> e becomes a 10-argument function (x1...x10) that returns a 5-argument
function (x11...x15).

Concerning untupling, a function that takes a N-tuple of arguments, where N is above the limit, remains a function that takes a single argument that is a tuple.

Currently, max_arity is set to 126 in native-code, to match the new representation of closures proposed in #9619. A signed 8-bit field is used to store the arity. 126 instead of 127 to account for the extra "environment" argument.

In bytecode the limit is infinity (max_int) because there are no needs yet for a limited number of parameters.

Copy link
Copy Markdown
Contributor

@mshinwell mshinwell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of comments:

  • Flambda can add extra arguments to functions during some of its unboxing passes, but they are limited by the number set in the Backend module (see optmain.ml). This should always be (much) lower than the new limit here, since the Flambda transformations don't want to break tail recursion.
  • Flambda uses the worker-wrapper technique for tupled functions, so I think this code needs modifying, to not do this transformation if the size of the tuple is over the limit. See tupled_function_call_stub in middle_end/flambda/closure_conversion.ml.
  • Could we please have a backstop in cmmgen.ml or thereabouts that ensures a fatal error is generated if we do end up generating functions with too many parameters?

@xavierleroy
Copy link
Copy Markdown
Contributor Author

Could we please have a backstop in cmmgen.ml or thereabouts that ensures a fatal error is generated if we do end up generating functions with too many parameters?

That's part of the other pull request, #9619, file asmcomp/cmm_helpers.ml, line 79.

@xavierleroy
Copy link
Copy Markdown
Contributor Author

Concerning Flambda, I'm not competent to work on it. Would you @mshinwell, or perhaps @chambart or @lthis, please update Flambda as appropriate? Feel free to push to my branch.

@mshinwell
Copy link
Copy Markdown
Contributor

@xavierleroy As per the comment I've just resolved, I was mistaken; I don't think we need to do anything with Flambda. This should be good to merge once the CI passes, then.

This commit introduces a quantity Lambda.max_arity that is the maximal
number of parameters that a Lambda function can have.

Uncurrying is throttled so that, for example, assuming the limit is 10,
a 15-argument curried function fun x1 ... x15 -> e
becomes a 10-argument function (x1...x10) that returns a 5-argument
function (x11...x15).

Concerning untupling, a function that takes a N-tuple of arguments,
where N is above the limit, remains a function that takes a single
argument that is a tuple.

Currently, max_arity is set to 126 in native-code, to match the new
representation of closures proposed in ocaml#9619.  A signed 8-bit field
is used to store the arity.  126 instead of 127 to account for the
extra "environment" argument.

In bytecode the limit is infinity (max_int) because there are no needs
yet for a limited number of parameters.
Addresses review comment.  To be squashed with 941c05b
@xavierleroy xavierleroy force-pushed the limited-uncurrying branch from 25c85d6 to 9d31539 Compare June 5, 2020 16:44
@xavierleroy xavierleroy merged commit 4aa90e9 into ocaml:trunk Jun 5, 2020
@xavierleroy xavierleroy deleted the limited-uncurrying branch June 5, 2020 16:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants