Hacker News Reader

That is a nightmare. You are telling me that the size of the stack of a function now depends on the fact that I modify an argument?

Also, you are masquerading an access trough a pointer as a direct access to some data. An access trough a pointer is less efficient than a direct access, and thus one could assume that is doing something efficient while in fact it isn't.

Finally, who guarantees that the programmer doesn't abuse this thing and starts to modify the data without doing the copy on write? On purpose or by mistake, the effect is that passing by value something will result in that something being mutated.

In the end, what is the problem of passing a pointer? It's more explicit and you know what is going on.

> There are huge wins for the cleanliness

What cleanliness? Because you think that

    void f(T *x);
    f(&x);

is not clean? Well, then use C++:

    void f(const T &x);
    f(x);

You cannot design an ABI that is supposed to be used by all languages on the fact that doing something in a specific language is more ugly than doing some other thing. If it's a problem of C, we should fix C, not change the ABI to change the semantic of C.

> An access trough a pointer is less efficient than a direct access

But the alternative is not "a direct access." It's a copy and then direct access. A copy, mind you, that occurs through a pointer to grab the original data from the stack position it was sitting in. That's the very same indirect read that the callee does in the proposed ABI!

Thus, the indirect memory read will happen either way; either at caller copy time (existing ABIs), or at read time (proposed ABI, copy optimized away), or at callee copy time (proposed ABI, copy not optimized away.)

The only difference in the number of indirect memory accesses, with the proposed ABI, is that you might be able to avoid an indirect memory write (i.e. of the memory the caller is writing to by doing the copy.)

> Finally, who guarantees that the programmer doesn't abuse this thing and starts to modify the data without doing the copy on write?

Uhh... we're not talking about features exposed to the developer. We're talking about calling conventions—instructions to the compiler on how to distribute the glue code it generates between the call-sites it builds ("caller-[verb]ed" things) and function prologues/epilogues it builds ("callee-[verb]ed" things.)

The "copy on write" part here [if you want to call it that—it's not "on" write] would be part of such a generated function prologue ("callee-copied")—the same code that gets generated at the call-site in existing calling conventions ("caller-copied"), just moved to the other side of the linkage. With the important difference that, if the compiler could prove that the callee (or anything it calls, passing the variable, transitively) wasn't going to do anything write-like with the data behind the pointer, then the copy in the function prologue could be optimized out.

This compiler optimization can only occur if the copy is the callee's responsibility. Given external linkage (think: separate compilation units, e.g. calling a function defined in a static library that's already compiled and only available in binary form), the caller can't guarantee the properties of the callee. But a callee can always guarantee its own properties during function-prologue/epilogue generation—since it's generating the function prologue/epilogue in the very same compiler session that has access to the AST that describes the function's static-analysis-proven properties in full.

(Yes, this means that a compiler could be mistaken about whether a callee writes through the implicit pointer underneath the passed value, and therefore generate the optimized function prologue when it shouldn't. This is known as a compiler bug, and wouldn't be something J Random Hacker would ever run into if using a stable, non-alpha release of their compiler, with a stable, non-alpha release of support for this calling convention.)

> What cleanliness?

The functionality being proposed is that you just pass-by-value (which makes obvious that the semantics your code is enacting is "the function can do whatever it likes with the value, and it won't affect the caller, because if it writes, it's writing to a copy of the value"); but sometimes it'll be automagically faster than it could have otherwise been, because sometimes, when the compiler can prove certain properties, no copy — only an indirect memory read — would be occurring.

This allows you to always use pass-by-value when you want those semantics, and to get code that's "as optimal as it can be"; rather than having to pass pointers around and explicitly copy-on-write and all that mess in order to get that same level of optimization.

(And yes, that's the alternative in heavily performance-oriented code like a database's tuple materialization logic. You don't get to write clean code at the expense of performance. Your "options" are to write performant code using dirty hacks; or fix the conventions you're coding on top of so that performant code doesn't require dirty hacks.)

> But the alternative is not "a direct access." It's a copy and then direct access. A copy, mind you, that occurs through a pointer to grab the original data from the stack position it was sitting in. That's the very same indirect read that the callee does in the proposed ABI!

Depends. If the structure was constructed in the caller and not needed afterwards the compiler could choose to directly construct it in the stack space used for the function call.

> What cleanliness? Because you think that > > void f(T *x); > f(&x); > > is not clean? Well, then use C++: > > void f(const T &x); > f(x);

To be honest, the first option is much better for readability. Visual inspection of the caller lets the reader know whether or not f can modify x.

That second option is horrible for the maintenance programmer who is reading the caller; whether or not you are interested in what the function f() does, you need to actually look it up to see if it is allowed to modify x.

A problem would be that performance becomes brittle. So you change the strict in your function and suddenly the program is slower.

That war was lost decades ago.

> In this scheme, the caller would pass non-register-sized data "by value" by actually passing a pointer to it. (Importantly, this pointer is register-sized, and so wouldn't necessarily need to be spilled to the stack—unlike caller memory copy, which is always to the stack.)

Sane ABIs already pass by-value parameters via up to two registers (or via vector registers). One register is just to small for many common things like 3D/4D vectors or start+end pointer pairs.

> Internal symbols — private static functions — get bespoke compiler-specific ABIs that skip all this enforced caller/callee predetermined role business and just codegen whatever's most efficient on a case-by-case bases, with different callsites getting different monomorphizations or partial inlinings of the callee that distribute the responsibilities differently.

Unfortunately this is still an area where compilers could do a lot more.

Other parts of the program can modify the object after the callee has started, if the callee contains some synchro there would be no race. At this point maybe you can think of additional tricks like CO"W" before any potential synchro point if some exist, but I'm not sure big advantages would remain except if you very carefully craft your program knowing all of that for the opti to happen, and it seems a lot of complexity in the compiler for limited gains, especially since if you have to massage the code you could as well transform to a reference yourself at source level (and that would better resist to e.g. calling unknown functions from the callee)

In order for another part of the program to do that, you would already have had to generate a mutable pointer to the object somewhere. As the article actually already goes into, this is something the compiler already tracks in order to know if a value needs to be loaded from memory when using it again.

If the ABI specified that objects passed this way were passed by immutable pointer, then just passing the object using this new method doesn't generate a mutable pointer, so the compiler is free to assume nobody else can modify it.

But that means the caller also has some proofs to do, if a counter example is found or nothing can be proven the caller also has to do a copy, and that's with no guarantee the callee won't do another one...

So not really an optimization anymore.

You say "proofs" but, as I said, this is already something the compiler keeps track of.

The caller is required to do a copy as the ABI is right now so if you can't do this optimisation it's only as bad as it was before.

Yes, there is a case where this creates one extra copy. The case where you a) give away a mutable pointer to a variable before calling another function, and b) the called function modifies it's own argument and then c) that function then doesn't use that object as the argument for another function it calls.

That's the only case where it generates an extra copy, and I'm going to go out on a limb and say that I'm almost cirtain that this will reduce sigificantly more copies that it creates.

Even if the called function (call it B) does use the object as an argument for another function it calls (call it C), B could end up having to perform another copy for that call, if B also takes a pointer to the variable at some point and lets it escape. Or a pointer to any part of the variable.

And it’s not limited to mutable pointers. Sure, if the variable itself is marked const, then it’s UB to modify it. But const local variables are rare in most codebases, in my experience. If on the other hand you pass the address of a non-const variable as a function argument, even if the type of the argument is a const pointer, the function can legally cast away the const and write to the pointer.

Still, I agree that this would probably eliminate more copies than it creates. But I don't think it would eliminate or create very many copies. In my experience, approximately nobody writes code that passes structs by value in the first place.

You know what this would mostly affect? Code that passes longs or doubles by value, when compiled for 32-bit architectures (like many modern ARM microcontrollers still are.) Something doesn’t have to be a struct to be larger than a machine register.

Also, FYI (sibling post because my first one is already locked): this isn't about what the programmer tells the compiler. It's about what the compiler can infer on its own, through dataflow analysis.

"const", as a qualifier, isn't novel information about a variable for the compiler — compilers already know whether a variable is used mutably or not, just like they know when and where a variable has its last access and goes dead.

"const" is an instruction to the compiler that if it finds, by its own independent analysis, that the variable cannot be const in that context, then the program is invalid and compilation should error out.

As such, "const" only even has a meaning, if the compiler already independently knows which declared variables are or are not const "in practice."

That information is what would be used to decide whether to do the copy.

> B could end up having to perform another copy for that call

At worst, that's no worse than what happens under the current ABI, where A passes data by value to B, which passes it by value to C.

(Do also remember, as I said in another comment, that ABIs/calling conventions are only "about" functions with external linkage. Functions with "static" linkage do whatever the compiler likes; as do their callers.)

I think, in the specific situation you're describing, there's also prelink-time cross-unit optimizations that can be done here to eliminate redundant copies even further — but that's getting close to just expecting C to do Rust-like ownership analysis, so I wouldn't claim that to be practical in any production compiler in the near future.

Copy-on-write is exactly what G++ and libstdc++ did with std::string before C++11 changed the spec. And it was terrible and full of bugs.

I remember how I had to solve a pile of thread bugs in a C++ project by changing string assignments into iterator constructors which would bypass the GNU CoW reference counter.

They tried, and tried, but never quite succeeded in fixing every single possible race condition with the reference count CoW implementation.

Copy-on-write is not fundamentally what we're talking about.

Copy-on-write is "the called function receives the original, but if it needs to write, then there's explicit code that makes a copy and replaces the reference to the original with a reference to the copy."

What we're talking about here is:

• A function is being compiled. It receives one of its formal parameters "by value." That parameter's data is larger than a machine-register in size.

• The compiler uniformly generates the call-sites of this function to provide the address of the original data, passing it in a register. The call-sites of the function look the same whether or not the function does the copy.

• The compiler, by static analysis of the function, determines whether the function really needs a copy—i.e. whether it would make a difference to the code whether the copying ever happens.

• If it needs a copy, then the compiler generates the function to have a prologue that does a copy from the address in the caller-passed register to the address in the stack pointer; and then the compiler generates code that interacts with the copy as a local stack variable. (Because, after the copy, it is!)

• But if the function doesn't actually "need" a copy, then the compiler generates no copy in the function prologue, and generates code for the function body that interacts with the original indirectly through the passed address in the register."

This has nothing-at-all to do with copy "on" write. This is "copy now, if we can't guarantee there won't be a write later."

Which is already what compilers do. That's what "pass by value" means. It's just that current calling conventions restrict compilers from being able to ever make that guarantee; whereas under the proposed calling convention, they would sometimes be able to make that guarantee.