winch: Multi-Value Part 1

[saulecabrera]

This change adds initial support for the Multi-Value proposal to Winch, focusing on function calls, support for Multi-Value for blocks will be added on top of this change in a different pull request.

This change is divided into two main parts:

• Infrastructure changes needed to support Multi-Value
• Handling Multi-Value returns for function calls

Infrastructure changes needed to support Multi-Value

Some notable changes were needed in order to support this proposal, namely:

• Introducing the notion of ABIOperands and rewriting the ABIParams and ABIResults in terms of ABIOperands.
• In Winch's default calling convention, results are stored in reverse order: if a function produces multiple results, the first result is stored in a memory location and the last result is stored in a register; given that function results are captured in the value stack after a function call, this approach makes it trivial to maintain the following value stack invariants:
  • Spilled memory values always precede register values
  • Spilled values are stored from oldest to newest, matching their respective locations on the machine stack.
• Introducing type-sized spills: Prior to this change, only floats produced type-sized spills, this created an inconsistency on how slots for results are handled and made it harder to manage the stack for multiple-results; this change introduces type-sized spills for integer and floats, making the spilling strategy uniform across the compiler. This might introduce some overhead, since this change is now, in the 32-bit case, introducing two instructions were previously there only used to be one (e.g. push vs sub + mov). My intention is to profile, and try to improve this strategy if needed, later on.

Handling Multi-Value returns for function calls

The approach for handling multiple results for function calls involves:

Adding an implicit extra parameter to the ABIParams definition, when a function returns multiple values; from the callee's perspective, this parameter is treated like any other "special" parameter (e.g VMContext), to which, we give it a well know LocalSlot for later referencing when storing the return values. From the caller's perspective, extra stack space is created before the call, and the address to that space is passed in to the callee, via the return pointer parameter and once the function returns, the values in the created space are captured as values in the value stack.

[github-actions]

Subscribe to Label Action

cc @saulecabrera

Details

This issue or pull request has been labeled: "winch"

Thus the following users have been cc'd because of the following labels:

• saulecabrera: winch

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[fitzgen]

LGTM but I'm still a little sketched out by those disassembly changes where I feel like I'm only seeing one half of a change or something like that. Maybe you can explain what is going on?