runtime: allow over-aligned types in the runtime #42143
Conversation
compnerd
changed the title
compnerd
force-pushed
the
malign
branch
3 times, most recently
from
aa3db3e to
4ad6e2d
Compare
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please clean test Linux platform |
|
@swift-ci please test |
|
@swift-ci please test |
|
@swift-ci please test Windows platform |
|
@swift-ci please test |
|
@swift-ci please test Windows platform |
|
@swift-ci please test |
|
@swift-ci please test |
Not all targets have a 16-byte type alignment guarantee. For the types which are not naturally aligned, provide a type specific `operator new` overload to ensure that we are properly aligning the type on allocation as we run the risk of under-aligned allocations otherwise. This should no longer be needed with C++17 and newer which do a two phase `operator new` lookup preferring `operator new(std::size, std::align_val_t)` if needed. The base type would be fully pre-processed away. The empty base class optimization should help ensure that we do not pay any extra size costs for the alignment fixes. As we are a C++14 codebase, we must locally implement some of the standard type_traits utilities, namely `void_t`. We take the minimal definition here, assuming that the compiler is up-to-date with C++14 DR reports which fixed an issue in SFINAE. We use the SFINAE for detecting the presence of the `operator new` overload to guide the over-alignment, which is inherited through the new `swift::overaligned_type<>` base type. Annotate the known classes which request explicit alignment which is non-pointer alignment. This list was identified by `git grep ' alignas(.*) '`.
|
@swift-ci please test Linux platform |
|
@swift-ci please test macOS |
|
@swift-ci please test Windows platform |
|
@swift-ci please test macOS platform |
|
@swift-ci please test Windows platform |
|
@swift-ci please test macOS platform |
|
@swift-ci please test |
|
@swift-ci please test macOS platform |
|
@swift-ci please test Windows platform |
|
It appears this pull broke building the stdlib for Android armv7, both on the community CI and my Android CI that builds a standalone SDK. @compnerd, what do you think, does this work for Win32? |
|
This does work for Win32. Interesting failure - what happens if you add Android to the Win32 case (assuming you get to the rest before I do) for the invalid overload of the placement new operator? |
Not all targets have a 16-byte type alignment guarantee. For the types
which are not naturally aligned, provide a type specific
operator newoverload to ensure that we are properly aligning the type on allocation
as we run the risk of under-aligned allocations otherwise.
This should no longer be needed with C++17 and newer which do a two
phase
operator newlookup preferringoperator new(std::size, std::align_val_t)if needed. The base typewould be fully pre-processed away. The empty base class optimization
should help ensure that we do not pay any extra size costs for the
alignment fixes.
As we are a C++14 codebase, we must locally implement some of the
standard type_traits utilities, namely
void_t. We take the minimaldefinition here, assuming that the compiler is up-to-date with C++14 DR
reports which fixed an issue in SFINAE. We use the SFINAE for detecting
the presence of the
operator newoverload to guide the over-alignment,which is inherited through the new
swift::overaligned_type<>basetype.
Annotate the known classes which request explicit alignment which is
non-pointer alignment. This list was identified by
git grep ' alignas(.*) '.