Layout of vector types #47
Conversation
|
|
||
|
|
||
| * Should unions containing a vector type and any number of ZSTs also be vector | ||
| types? For example, should `MaybeUninit<Vector<T, N>>` also be a vector type? |
There was a problem hiding this comment.
Which consequences does it have to answer this with "no" or "yes"? I don't understand what "being a vector type" entails.
I would find it strange if this document said anything about unions; that should all fall out of the general union rules. In terms of layout, repr(C) unions have all their fields starting at offset 0 and hence if all but one variant are size-0-align-1, their layout (at least size and alignment) is identical to that of the only non-ZST field.
There was a problem hiding this comment.
I don't understand what "being a vector type" entails.
It affects the calling convention, e.g., when interfacing with C (vectors are not aggregates). So depending on what we decide here, one might be able to use MaybeUninit<Vector> when interfacing with C or not. Calling conventions are neither representation nor validity AFAICT, so I don't know when and where to discuss this, but we should not forget about it. It also affects what kind of optimizations LLVM can do, which do differ depending on whether MaybeUninit<Vector> is a "vector" or not.
I would find it strange if this document said anything about unions; that should all fall out of the general union rules.
Yes, this should be resolved more generally in the context of unions. MaybeUninit<T> is a general construct, and we might want it to be an aggregate only if T is an aggregate, but not if e.g. T is c_int.
This document should, at most, repeat what's mentioned about this somewhere else.
There was a problem hiding this comment.
Ah so this is about ABI then. Yeah I have no idea.^^
|
Note: I've opened rust-lang/stdarch#607 to require documenting not only the size but also the implementation-defined alignment of the x86 and x86_64 vector types. |
|
So I made |
Closes #38 .