Chapter 18 Function representation

[dibyendumajumdar]

Hi,

I am trying to understand a couple of things about functions.

Why are function nodes modeled as regions and arguments as phis. Was this design driven by a desire to simplify inlining? Or is this because arguments of a function can be modified later in the function so its useful to make them Phi nodes to start with?

It would be good to discuss the design choices available, what C2 and other SoN implementations do.

My second question was with regards to the RPC - what is this and how is it used? Reading chapter 18 I had thought it was just to support the evaluator but I see that this is also being used on codegen in chapter 21. So it seems the RPC is more of a hard requirement?
What would be the alternative to RPC?

[cliffclick]

"Why are function nodes modeled as regions and arguments as phis. "
Because they are regions & phis, with a tiny bit more extra features.
Functions merge control flow from all Callers, exactly as a Region does.
Parms merge arguments at Functions, exactly as Phis to Regions.

If we put them in as separate nodes, but also want to optimize a whole compilation unit, we'd basically have to cut-n-paste replicate Regions and Phis.

When compiling single functions at a time, you do not get to optimize the common arguments to a function, nor do you need to worry about who calls whom, and you can use a simpler implementation.

Simple is compiling whole compilation units; its still all linear time optimizations just at a higher quality level.

[cliffclick]

"My second question was with regards to the RPC - what is this and how is it used?"

Return Program Counter. Its where you return too after a call. This, plus the stack contents, amounts to a "current continuation" - the "rest of the program" to be executed. Every chip on the planet has a way to make and use these; and generally has substantial hardware support for the RPC so you need to directly deal with it.

"What would be the alternative to RPC?"

There is no alternative to the RPC except never to make any calls. The act of calling implies the act of coming back/returning... and this is exactly what the RPC is. There are many alternative ways to manage the RPC.
X86 pushes it on the stack at a CALL - crushing a word of stack, and modifying the RSP. The X86 RET op pops (modifies) the RSP, pulls the RPC from the stack and jams it into the PC. The requirement to balance the stack comes directly from the hardware.
RISC/ARM have a "jump and link" for the CALL; jump to the call address and put the RPC in a normal GPR. The RET here stuffs the RPC value from a register to the PC. The register does not have to be any particular one.
Old Fortran compilers would work without a stack (so no recursive calls); the RPC would be stored in a static word per-function, and loaded from there to return.

[dibyendumajumdar]

I get that at the level of x86/arm instructions a mechanism is needed to pop the stack frame, but what does this mean at the SoN level? Is it really necessary to have the RPC node? Could this be handled just when generating code?

[cliffclick]

For x86-only, yes. For a portable compiler the RA needs to know what register gets clobbered by the RPC during a call - and on RISC/ARM style chips there's an optimization opportunity on leaf calls to not spill/reload the RPC. So I voted for making the RPC "well known" and now I don't need to deal with it special for every chip that comes around.

[dibyendumajumdar]

@cliffclick for a CCC session, request a deep dive into function calls and how they are implemented in SoN - and how that flows into the code gen.

[dibyendumajumdar]

If you are happy to do the deep dive, please let me know the session I would like to join