How do you handle arbitration between spilling call-preserved registers on the stack and the creation of new functions?

The way I see that, and I may be severely wrong: once I filled all the called-preserved registers, I would spill on the stack, but if I end up spilling on the stack all call-preserved regs, I do create new functions.

I don't use register spill as a criterion for creating functions.

If I use some non-trivial code more than once then I will consider making it a function.

The final call will be made based upon what I need to optimise for. If I need peak performance then I will benchmark each way to decide. If I want good readability then I usually just make a new function. If I need to move on quickly to meet a deadline then I often just copy/paste with the (often unmet) hope to come back later to "fix" it.

Indeed, the "trivial and more than once" usually does pre-empt spilling leading to function creation, that upon initial coding.

The functions I am talking about would have very probably only one call-site (ooof) and would be non-trivial (their state would eat a good part of call-preserved regs since many would perform ABI calls).

I guess I should eat the bullet: handle such huge code path with reg spilling all over the place. I should start to figure out a not too disgusting way to handle deeply nested labels (here, I use a basic C pre-processor).

My computer science professor called it cohesion and containment. Is the function cohesive - does it do one thing well and not anything else? Is the function contained - not linked to many external things? If those things are true then you have a good function.

As we scale to greater complexity we're asking the questions at a complexity scale. This is systems thinking.

* disclaimer: that's advice from the late 80's.

I am talking sorta more about ABI functions.

In C and similar, we write more 'logical' functions than ABI functions.

In assembly, many C functions would end as just some code blocks.

In the end, with now more perspective, I write ABI functions in assembly for flexibility mostly since I am in the middle of the dev elopment cycle: program structure is far from being stabilized.

Once program structure does settle down, some ABI functions will probably move as 'code block' functions: both are 'logical' functions following the guidelines you talked about.