undefined | Better HN

0 pointsmeindnoch1y ago0 comments

So you're saying that turning std::span from a standard library class into a language feature wouldn't break the ABI? How so? How would such a language construct fit into the existing ABI?

(for context: parent is referring to the fact that x64 calling conventions mandate structs larger than 64 bits to be passed in memory, which means that passing a 128bit std::span is going to be less efficient than passing a separate 64bit index and 64bit length, as those can go into registers)

0 comments

maccard1y ago

No, the cat’s out of the bag with span (and unique pointer) now, we can’t go back. We knew this was a problem from unique_ptr and had an opportunity to not make the same mistake again, but instead we chose back compat for a new feature over something novel and performant

gpderetta1y ago

What is the issue exactly? Span is trivially copyable and destructible and, at least with the Itanium ABI, it can be passed (and returned) via registers: https://gcc.godbolt.org/z/4rbcshve4 .

Other ABIs might have different constraints but there is no reason why they couldn't special case std::span. In fact if span was a built-in type there is nothing preventing a compiler form picking a suboptimal ABI and being stuck with it. In any case it is not a standardization issue, but purely a QoI.

meindnochOP1y ago

Yes, GCC can pass it in two registers. On the other hand Microsoft's x64 ABI doesn't:

>Structs and unions of size 8, 16, 32, or 64 bits, and __m64 types, are passed as if they were integers of the same size. Structs or unions of other sizes are passed as a pointer to memory allocated by the caller.

https://learn.microsoft.com/en-us/cpp/build/x64-calling-conv...

maccard1y ago

The parent commenter handled the ABI question for me, but I want to respond to :

> In any case it is not a standardization issue, but purely a QoI.

This is an enormous problem in the C++ ecosystem - playing hot-potato with whose fault it is, instead of trying to actually fix it. Span is a decent example, the standards committee get to say it's a vendor issue, and the vendors get to say that their hands are tied by the ABI. The result is that people spend time arguing about who should fix it rather than actually fixing it.

gpderetta1y ago

That's all well and good, but what would you do exaclty? The standard comitee cannot impose an ABI as it would be ignored by implementors. Implementors either own the ABI (MS for example) and are responsible for their owns screwups or there are other bodies that are responsible (the informal forum for the inter-vendor Itanium ABI for another example).

In any case this has nothing to do with std::span being an technically a library type or a built in. There is really no fundamental difference between the two.

For example std::complex and std::initializer_list have special handling on many compilers, just to mention two types.

1 more reply

j / k navigate · click thread line to collapse

0 comments

maccard1y ago

gpderetta1y ago

What is the issue exactly? Span is trivially copyable and destructible and, at least with the Itanium ABI, it can be passed (and returned) via registers: https://gcc.godbolt.org/z/4rbcshve4 .

meindnochOP1y ago

Yes, GCC can pass it in two registers. On the other hand Microsoft's x64 ABI doesn't:

https://learn.microsoft.com/en-us/cpp/build/x64-calling-conv...

maccard1y ago

The parent commenter handled the ABI question for me, but I want to respond to :

> In any case it is not a standardization issue, but purely a QoI.

gpderetta1y ago

In any case this has nothing to do with std::span being an technically a library type or a built in. There is really no fundamental difference between the two.

For example std::complex and std::initializer_list have special handling on many compilers, just to mention two types.

1 more reply

j / k navigate · click thread line to collapse