Skip to content

Program transformation to uncurry functions for which all applications are fully saturated. #24

Description

@Unisay

Problem

Curried functions compile to nested closures. This

local add = function(x)
  return function(y)
    return x + y
  end
end

is about two times slower than

local add = function(x, y)
  return x + y
end

Approach

Rewrite the former shape into the latter, but only for functions that are always fully applied — i.e. no partial application such as add(i) ever happens in the program being compiled. The applications must be rewritten to match:

add(x)(y)  ===>  add(x, y)

Prerequisites / Relations

Depends on #179, which introduces the n-ary AppN node this transformation emits and consumes. In turn this unblocks #181 (loopification of self-recursive tail calls, which needs uncurried workers).

Verification / Measurement

A function that is only ever fully applied is emitted as a single multi-argument Lua function with its call sites lowered to direct f(x, y) calls (no intermediate closures), while a function with any partial application in the program is left curried. Curried-application overhead is ~4.3x under PUC and ~54x under LuaJIT today, so the win is the removal of that overhead on the rewritten call sites.

Metadata

Metadata

Assignees

Labels

OptimisationA Compiler Optimisationarea: irIR / optimizer / DCE / inlinerenhancementNew feature or request

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions