4 ms·

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:

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

meindnoch 2y 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-convention?view=msvc-170 https://learn.microsoft.com/en-us/cpp/build/x64-calling-conv...
maccard 2y 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.
- gpderetta 2y 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.
  - maccard 2y ago
    > That's all well and good, but what would you do exaclty? Start with having the standards committee accept that they are in fact where the buck stops, and that the language includes, whether they like it or not, the toolchain. They don't have to decide upon the toolchain, but their current MO of "toolchain/ABI issue == not our problem (except for when we decide we're not willing to make any backwards incompatible ABI changes, but only sometimes)." The vendors are already jumping through hoops to support what is being standardised (modules being the perfect example here). I can't speak for std.complex as I've never had to use it, but I think initializer list would be a great example of "how much better would this be if it was special cased into the compiler". The benefit we would get from initialisation being consistent with the compiler far outweighs the benefit of being able to use libc++'s initialiser list with clang. > There is really no fundamental difference between the two. Except there is. If I write an implementation of the standard library, and provide an implementation of std span as (abbreviated) - https://gcc.godbolt.org/z/c1sz4neKG https://gcc.godbolt.org/z/c1sz4neKG it's got to respect the various conventions instead of being treated as an opaque type (like a slice in go). If it's a `_Span`, the compiler is free to go "ok you're using this thing that I know all the internals of, and can reason about. I can elide bounds checks that don't pass muster, I can specify that I will generate code for this specific type that puts extent and data as registers in the following cases". But instead, on x64 (where I work 99% of the time so it's where my effort/knowledge is, sorry), we're bound by >64 == memory. Now, you might call that a QOI issue, but I'd call it a design flaw that could have avoided an implementation issue, that we see on many features.
    - gpderetta 2y ago
      > except for when we decide we're not willing to make any backwards incompatible ABI changes That's not an exception. The committee is not willing because the implementors explicitly said it is not going to happen, no matter how much Google cries. > Except there is. If I write an implementation of the standard library, and provide an implementation of std span if you write it as an user you are constrained by the ABI. But implementors are not: they can bless their own span with superpowers if they want to (in practice they would use special attributes). And there is no reason the compiler can't have builtin knowledge of the semantics of std::span (the same way it has knowledge of printf, malloc and the various math functions for example). > But instead, on x64 (where I work 99% of the time so it's where my effort/knowledge is, sorry), we're bound by >64 == memory. [Note this is an MSVC-specific ABI issue not a general x64 one. GCC uses the Itanium ABI on x64] But the MSVC issue is really a red herring: there is a-priori no reason to expect they would have picked a better ABI for a built-in _Span. The committee cannot force compilers to be optimal (it can't even force conformance). (Note I'm not singling out MSVC, GCC also has multiple less than ideal ABI decisions).

meindnoch 2y 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-convention?view=msvc-170 https://learn.microsoft.com/en-us/cpp/build/x64-calling-conv...

maccard 2y 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.

gpderetta 2y 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.
- maccard 2y ago
  > That's all well and good, but what would you do exaclty? Start with having the standards committee accept that they are in fact where the buck stops, and that the language includes, whether they like it or not, the toolchain. They don't have to decide upon the toolchain, but their current MO of "toolchain/ABI issue == not our problem (except for when we decide we're not willing to make any backwards incompatible ABI changes, but only sometimes)." The vendors are already jumping through hoops to support what is being standardised (modules being the perfect example here). I can't speak for std.complex as I've never had to use it, but I think initializer list would be a great example of "how much better would this be if it was special cased into the compiler". The benefit we would get from initialisation being consistent with the compiler far outweighs the benefit of being able to use libc++'s initialiser list with clang. > There is really no fundamental difference between the two. Except there is. If I write an implementation of the standard library, and provide an implementation of std span as (abbreviated) - https://gcc.godbolt.org/z/c1sz4neKG https://gcc.godbolt.org/z/c1sz4neKG it's got to respect the various conventions instead of being treated as an opaque type (like a slice in go). If it's a `_Span`, the compiler is free to go "ok you're using this thing that I know all the internals of, and can reason about. I can elide bounds checks that don't pass muster, I can specify that I will generate code for this specific type that puts extent and data as registers in the following cases". But instead, on x64 (where I work 99% of the time so it's where my effort/knowledge is, sorry), we're bound by >64 == memory. Now, you might call that a QOI issue, but I'd call it a design flaw that could have avoided an implementation issue, that we see on many features.
  - gpderetta 2y ago
    > except for when we decide we're not willing to make any backwards incompatible ABI changes That's not an exception. The committee is not willing because the implementors explicitly said it is not going to happen, no matter how much Google cries. > Except there is. If I write an implementation of the standard library, and provide an implementation of std span if you write it as an user you are constrained by the ABI. But implementors are not: they can bless their own span with superpowers if they want to (in practice they would use special attributes). And there is no reason the compiler can't have builtin knowledge of the semantics of std::span (the same way it has knowledge of printf, malloc and the various math functions for example). > But instead, on x64 (where I work 99% of the time so it's where my effort/knowledge is, sorry), we're bound by >64 == memory. [Note this is an MSVC-specific ABI issue not a general x64 one. GCC uses the Itanium ABI on x64] But the MSVC issue is really a red herring: there is a-priori no reason to expect they would have picked a better ABI for a built-in _Span. The committee cannot force compilers to be optimal (it can't even force conformance). (Note I'm not singling out MSVC, GCC also has multiple less than ideal ABI decisions).