Currently we disallow inlining in case of arity mismatch. This made sense when we were passing arguments in the wrong order, since arity mismatch calls required some call frame ninja work, and it seemed like adding this to the inliner would be sufficiently complex that avoiding it would reduce the bug tail. But now that we're passing arguments in the right order, inlining calls that pass too many arguments is trivial. There simply isn't anything standing in the way of us doing this. The value recoveries in the inline call frame already do the right things (they track the arguments passed, not the parameters expected). The argument flushing does the right things (it places the arguments where they should be and makes sure that they are really stored to the stack). The rest of the inlining machinery already computes the stack offset correctly. So while it's still the case that arity mismatches where too few arguments are passed are hard to inline, the ones that involve too many args are trivial and we should just inline those.
Created attachment 141089 [details] the patch
Comment on attachment 141089 [details] the patch r=me
Landed in http://trac.webkit.org/changeset/116620
Landed in http://trac.webkit.org/changeset/118144
Excuse me, merged in http://trac.webkit.org/changeset/118144