https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #13 from Benoit Jacob <jacob.benoit.1 at gmail dot com> --- (In reply to Richard Biener from comment #12) > (In reply to Benoit Jacob from comment #11) > > (In reply to Richard Biener from comment #10) > > > But ::operator new(std::size_t) could always return memory aligned for the > > > most over-aligned type? Thus our default new implementation could use > > > posix_memalign (..., MIN (size, BIGGEST_ALIGNMENT), size)? > > > > The problem is there are lots of use cases for really high alignment: AVX > > brings uses of 32-byte alignment, and cache lines are typically >= 64 byte > > aligned. So alignas has to support at least 64 or 128 byte alignment to > > support cache friendly code, and even without that, it would have to support > > at least 32 byte alignment for AVX vectorized code. > > > > Making all allocations that large would lead to substantial allocator slop. > > For example, jemalloc has a quantum of 8 or 16 byte depending on whether the > > arch is 32 or 64 bit, so increasing it to 32, 64 or 128 byte would be a big > > difference. > > Though does it really matter in practice? Tiny allocations would not suffer > because of the MIN (align, size), so the worst-case is max-align + 1 > allocations. Btw, you could as well try MIN (align, size & -size), > thus assume that the allocation size is N * alignof (). Oh, I was missing the MIN (size, BIGGEST_ALIGNMENT) part of your proposal. So you're right, that nicely takes care of tiny allocations. Correct also on MIN (align, size & -size) (though I have to trust your bit wizardry here) so that neatly exploits the low bits of the size parameter to infer the alignof --- sounds very good to me!
