Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix evaluation order for overapplications when using Closure #967
When using the Closure pass (i.e. non-Flambda) the evaluation order for overapplications does not match the bytecode compiler and Flambda: as shown by PR#6136, the subset of arguments forming the full application are evaluated first, then the function is called; and then the remaining arguments are evaluated. This patch fixes that by let-binding the arguments before the call.
I also think the rarity of these cases means that we shouldn't really be worrying about the performance impact of this change. Furthermore, constructing benchmarks that actually give meaningful results for changes like this probably isn't entirely straightforward, and given limited time I think our attention is best concentrated elsewhere (e.g. #966).
Would anyone like to comment on the correctness of this patch?