Hacker News Reader

Comment by nneonneo | Hacker News Reader

Hmm, I don’t agree. If you pass a structure by value, that is supposed to make a copy. The callee is free to modify the copy any way it likes (unless you use const, and that’s not much protection in C). Doing as the author suggests, and passing in an immutable parameter, would introduce copy-on-write semantics.

If the concern is the overhead of copying large structures around, the obvious solution is to not do that and simply pass structure pointers (like most APIs do). This also gives the API implementer (i.e. callee) full control over whether copies get made or not.

In fact, I think I’d argue that if you’re passing large structures by value, Your API Is Probably Wrong and this is absolutely not the ABI’s problem in the first place.

View on HN

The explaination by derefr is correct.

But there is a larger assumption that underlies your post that I think is important to correct.

You seem to be caught up in the idea that the code you write, and the code the compiler generates must have some kind of one-to-one corrospondance, but this isn't the case at all.

The code the compiler generates must have the same final result, but it doesn't have to actually work the same way.

So if you pass a structure by value, and the compiler can avoid a copy somehow because it's more efficient, then of course it should do so.

Making an ABI that is ammenible to allowing the compiler to make better optimisations is of course also a good idea. And the proposed ABI here achieves that.

> The code the compiler generates must have the same final result, but it doesn't have to actually work the same way.

You're obviously correct, but I think this ignores downstream costs of sufficiently magical compilers. If my compiler tunnels into a parallel universe, executes the code there, and returns the result, that's fine, but it's going to be enormously painful to debug.

Obviously very few developers (including myself) have an appropriate mental model of highly complex, speculative processor architectures that end up executing their code, but I do think there is at least some benefit to having a correspondence between the code you write and the code the compiler generates.

Maybe it's not a problem with the compiler, but a problem with languages. Maybe we just need better languages?

Doesn't this hurt forward compatibility to new architectures where there are more registers and it would be more efficient doing it through registers? Seems like automatic choice by the compiler should be default and if explicit control is needed some kind of attribute or something could be used to override the compiler's choice.

Not really because ABI's are already architecture specific so they already do stuff different for other CPUs. Similarly, their are already a variety of attributes that can be used to explicitly control the ABI of the top of my head things like packed structs and function calling convention are common and in several languages (C, C++, rust and zig).

> You're obviously correct, but I think this ignores downstream costs of sufficiently magical compilers. If my compiler tunnels into a parallel universe, executes the code there, and returns the result, that's fine, but it's going to be enormously painful to debug.

> Obviously very few developers (including myself) have an appropriate mental model of highly complex, speculative processor architectures that end up executing their code, but I do think there is at least some benefit to having a correspondence between the code you write and the code the compiler generates.

It’s not really clear to me why you think this? Or at least, it’s not clear to me how you can write this without levelling the same complaint against essentially any C compiler written after the mid 1980s?

Because for all the hand—wringing in the comments here about compilers generating code that doesn’t do what your C said it would do in the way you wrote it, that ship sailed decades ago.

That quaint little integer addition loop you write in C will, as like as not, be exploded by the compiler into an unrolled stream of SIMD instructions and packed registers that doesn’t resemble what you wrote in the least, which the CPU may then further scramble and interleave, resulting in nothing remotely like what a naive person might imagine is a reasonable translation of what you wrote – and yet, debuggers remain broadly useful tools.

And people have for decades now shown a strong desire to enthusiastically and with great speed drop compilers in favour of newer ones that performed better optimizations, which is to say, people have shown a strong preference for compilers that are good at generating code that looks nothing like what you wrote, provided the results are the same and the performance is as fast as possible.

Turning a copy into passing a pointer that may later copy if and only if the compiler sees the possibility of a write coming is, in terms of modern optimizations, an absolutely conservative optimization that doesn’t routinely happen only because platform ABIs unnecessarily rule it out. Far from being a bridge too far, in terms of modern compiler behaviour it’s simple and low-hanging fruit which isn’t exploited even though far more exotic tricks are already the rule of the day.

GCC and LLVM already do this, the idea of what you wrote is still there, if you want to debug add debug info, DWARF exists for a reason.

Dropping one-to-one correspondence is fine for most code, but there are certain places where it is unacceptable. An ABI is one of these places, because the interface is designed to be exposed in a way that is observable.

> The code the compiler generates must have the same final result, but it doesn't have to actually work the same way.

It doesn't, but when it comes to debugging, it would help to have them similar.

> Doing as the author suggests, and passing in an immutable parameter, would introduce copy-on-write semantics.

Yes, and what's wrong with that, if it's transparently done by the compiler?

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.)

A callee that can be statically determined to never modify the value, would, under this calling convention, be compiled to code that simply works with the data "through" the pointer that's been placed in its register / on the stack.

A callee that can't be statically determined to never modify the value, would, under this calling convention, generate a memcpy from the pointer onto the stack; where the pointer then goes dead at that point (and so, if the pointer was spilled to the stack by the caller, then the memcpy could be targeted so as to overwrite the pointer on the stack.)

This would be much more efficient under most conditions. Its only inefficiency would come from the situation where the pointer being passed would necessarily be spilled to the stack; and then the callee would be statically guaranteed to make a copy. In that case, you're doing an extra push (for the pointer) that current ABIs avoid by just having the caller do an eager copy.

But this would be quite rare in practice, since this ABI (and the ABIs it replaces) are only for external symbols — the kind whose linkage is fundamentally dynamic (i.e. where the linker-loader could in theory substitute anything it likes for the external symbol with an LD_PRELOAD shim.)

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.

And since these ABIs only matter for external linkage, you have to remember that symbols with external linkage get no "type attribute enforcement" at link-load time, and so your symbol for a function that was originally guaranteed to be a callee-that-always-writes, might be substituted at link-load time for a callee-that-never-writes. In which case, having the pointer on the callee's stack once again becomes handy, rather than useless.

> In fact, I think I’d argue that if you’re passing large structures by value

Not necessarily large structures. More often things like UUIDs—values just large-enough to not fit into a (64-bit) machine register. It's these small memory spills, done in hot loops, that add up. There are huge wins for the cleanliness of e.g. RDBMS engine code, if their various 128-bit to 512-bit column types can be passed by value without necessitating an eager copy.

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.

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.

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.

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.

> 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.

> and passing in an immutable parameter, would introduce copy-on-write semantics.

Yes that’s the point the author is making. His scheme incurs strictly less overhead than the scheme currently used.

Some people may want to program in a “value oriented” way without pointers at the C level for various reasons but for efficiency reasons they cannot.

Reply on news.ycombinator.com