If you stripped the arity how would you know how many register need to be moved into the new call routine's register list, so that reordering, clobbering, etc. at the call site are optimized?
I am a bit rusty on the specifics of the BEAM's registers (the VM that Erlang and Elixir run on) but IIRC the short version is these are registers in a VM and the VM takes care not to let them clobber.
Also, in the BEAM, intra-module and inter-module calls operate differently.
> BEAM is a register machine, where all instructions operate on named registers. Each register can contain any Erlang term such as an integer or a tuple, and it helps to think of them as simple variables. The two most important kinds of registers are:
> * X: these are used for temporary data and passing data between functions. They don’t require a stack frame and can be freely used in any function, but there are certain limitations which we’ll expand on later.
> * Y: these are local to each stack frame and have no special limitations beyond needing a stack frame.
The Erlang VM absolutely clobbers registers within functions all the time, since there are only 64? of them and they are a 'limited' resource. My point is that the logic to efficiently move data around is more complicated when you don't know the arity ahead of time.
You can't, for example, keep a register file as a linear slice. You have to allocate a whole slate of 64 registers on each call with the last (n) registers blanked.
