Anon (no.delete@this.spam.com) on September 22, 2022 5:48 am wrote:
> rwessel (rwessel.delete@this.yahoo.com) on September 22, 2022 5:25 am wrote:
> > VAX CALLG/CALLS did exactly that. The function would have a procedure entry mask which specified
> > which registers* would be saved by the call instruction, as well as a few other things.
>
> CALLG/CALLS were actual instructions? I think people mis-understood me here, I am not saying
> there should be new instructions, I am saying that function metadata (maybe die hard C fans
> have a problem to understand what I mean here, the symbols, the parameter list, the function
> descriptor, etc) could include information about register the function uses, any function calling
> that function should saved those register or include that information in it's own metadata for
> propagation, the compiler uses the metadat to generate optimal register allocation.


Yes, CALLG/S were actual instructions.

But as I pointed out, compilers should already do that, at least with functions that don't have a need to follow the ABI. Or, in many cases, inline the functions, and remove the need to do any of that at all. And remember that regularly occurs across translation unit boundaries with link time code generation. The place where it can't is across executable modules (since they're separated, the calling convention - not necessarily following the ABI* - needs to remain predictable).

To consider a very simple case:

static inline int f(...) {...; return ...;}
int g(...) {...; x=f(...); ...;}

Any semi-competent compiler should ignore the system ABI completely, and generate register spills only as needed for other reasons. Even if f() isn't inline, the compiler can adjust the calling convention however it likes. Again, translation unit boundaries shouldn't matter either.

If you're suggesting that register usage could be added to the ABI in some fashion, no that's not usually done, and I'm not sure how it really could be, the ABIs are often used to define interfaces where the two sides (caller and callee) are built at different time. The first thought would be to add such information to the name decoration, but that happens at the wrong time, with incomplete information, for something like callers in C++. JITs, of course, could optimize across such boundaries, at least in some cases.


*For example, many of the functions in the CRT** can be external (in a shared library/DLL), but often don't follow the system ABI very well. The calling convention needs to be fixed enough that the compiler can generate the required call, but it doesn't need to follow the ABI.

**As distinct from the C library (even if both often end up physically in the same shared library).