Better fix for throw argument thing (I think)

[Wuerfel21]

There is neither a bug tracker entry, a test case nor a description of what the problem was, so I'm assuming the problem was just the generation of Arg registers unrelated to a normal function call and this fixes it more properly.

[Wuerfel21]

I think there's actually a case where the current thing fails:

• There's 3 functions (let's assume all of them are zero-arg):
  • A has a throw
  • B calls A
  • C calls B
• A is inlined into B
• The optimizer eliminates the longjmp call, but not the moves into arg registers (many ways that can happen)
• B is marked effectively leaf because all OPC_CALL are deleted
• C can (given peek-args) now assume that B clobbers no arg register, when it actually does

This PR fixes it because maxInlineArg is propagated up the call tree.

[totalspectrum]

I need to think about this one. Maybe the right answer is just to never inline functions that contain a THROW; that should be rare enough to not affect to much. What do you think?

[Wuerfel21]

Is there anything special about THROW/longjmp vs a regular function call? If not, there really isn't a point in special-casing it.

I think there's value in inlineing THROW functions because constant propagation ought to be able to delete the throw check in many cases (eg if it's behind a check for valid arguments).

Somewhat relatedly, I think peek-args can be made more robust by updating maxInlineArg based on arg registers actually found in the IRL during ExpandInlines. That may make it -O1 (or at least -Os) tier again. Maybe it should be renamed to maxClobberArg then... Should write that up as a PR.

[Wuerfel21]

(rebased on master - oops tests are still broken)