all: avoid clobbering BP register

[mmcloughlin]

See discussion on Slack and golang-dev

https://gophers.slack.com/archives/C6WDZJ70S/p1598210629000900
https://groups.google.com/g/golang-dev/c/aLn9t8tKg2o/m/Kw-N7lUuBAAJ

Summary:

• BP should be callee-save (poorly documented, even some standard library assembly didn't handle this correctly until recently)
• BP "will be saved automatically if there is a nonzero frame size" https://golang.org/cl/248260

avo needs to handle this somehow. Suggestions:

• Use the "nonzero frame size" hack in the case where BP has been used
• De-prioritize BP in the register allocator
• Just don't allocate BP? People can still use it directly as a physical register. https://gophers.slack.com/archives/C6WDZJ70S/p1598290724032300
• Allow an override for the (presumably rare) case where someone needs a 0 stack frame and to use BP, and they'll save it themselves. "maybe avo.NoClobberBp() ? avo.SavingBPMyselfPromise() ?" https://gophers.slack.com/archives/C6WDZJ70S/p1598290549031600

[armfazh]

If during code generation, avo needs to use BP then it must be saved, which in turn requires at least 8 bytes in the stack.
So this is not possible: someone needs a 0 stack frame and to use BP

De-prioritize BP in the register allocator Yes definitely, BP can reside in the bottom to the list used for register assignment.
A more drastic alternative is not to use BP at all, but I think a push&pop operation is not so bad.

[mmcloughlin]

Just to test the simple solution, I tried marking BP restricted so it would be excluded from allocation #173. This caused some avo examples to fail, and broke one of the third-party tests.

Therefore, I think the more nuanced solution is worth pursuing, specifically de-prioritizing BP in the allocator, and then applying the "non-zero frame size hack" in the event that the allocator chooses to use BP.

[mmcloughlin]

For reference, the relevant parts of the assembler are:

• Decision point on whether BP should be automatically saved: https://github.com/golang/go/blob/bb54a855a9b5733569f40ac19a2c338b87c23d14/src/cmd/internal/obj/x86/obj6.go#L584-L602
• Save: https://github.com/golang/go/blob/bb54a855a9b5733569f40ac19a2c338b87c23d14/src/cmd/internal/obj/x86/obj6.go#L666-L691
• Restore: https://github.com/golang/go/blob/bb54a855a9b5733569f40ac19a2c338b87c23d14/src/cmd/internal/obj/x86/obj6.go#L884-L895

[Yawning]

First of all, thanks for avo, it has been useful and helped me make what formerly was a gigantic collection of .s files much easier to maintain.

For what it's worth, the way I am working around this problem for now is to use a nasty kludge involving reflection and unsafe to mark BP as restricted, since I know that I do not need to use rbp as a GP register, and the only thing causing issues is the register allocator.

While this case should be addressed by the allocator gaining a notion of priority, it would be nice for me to continue to take this general approach (preferably without unsafe/reflection).

My current thinking is that in the event that I write something that actually needs every single register in the future after avo starts applying the non-zero frame size hack, I would prefer to handle allocating/saving/restoring rbp myself.

Some minor questions regarding the "non-zero frame size" hack:

• If the routine handles saving/restoring rbp, will avo not apply the hack?
• In the event that the hack is required, and the routine has the NOFRAME attribute, what happens?

[mmcloughlin]

I have landed #174 and #184 which should de-prioritize BP in register allocation, and apply the "frame size hack" if it must be used. I believe this fixes the immediate problem at hand, so I will close this issue, but that doesn't mean there's no more work to be done related to this.

@Yawning Thanks for your comments. I think the answer to your questions is configurable "compilation options", which could be applied globally or per function. In this case, I could imagine two options: one that controls whether BP is available for allocation at all, and another to control whether avo will attempt to automatically save BP. Do you think this would suffice? I've filed #185 for this feature more generally since there are other use cases for configuration like this.