On Mon, Nov 22, 2021 at 1:08 PM David Goldblatt via Phabricator < revi...@reviews.llvm.org> wrote:
> davidtgoldblatt added a comment. > > (For background: I'm a jemalloc maintainer and wrote N2293). > > In D100879#3145361 <https://reviews.llvm.org/D100879#3145361>, @rjmccall > wrote: > > > Platforms are permitted to make stronger guarantees than the C standard > requires, and it is totally reasonable for compilers to assume that > `malloc` meets the target platform's documented guarantees. Arguably, > libraries should not be replacing `malloc` if they fail to meet the > platform's documented guarantees. > > I agree generally that assuming platform guarantees is reasonable for the > compiler in targeting that platform, but I don't think I agree that the > dlmalloc alignment is one of them. Well, IIRC it's documented in the platform manual for `malloc`. I suppose one could argue that it's an implementation property which is only guaranteed for unreplaced `malloc`s, but that's not what I would naturally assume from reading the manual, and you'd think there would be a warning that library code can only assume a weaker alignment. I suppose you could also argue that the manual itself is implementation-specific, but platform guarantees have to be documented *somewhere*, and conventionally that's the standard manual. Still, if you can get glibc to confirm that the intent is that replacement `malloc`s aren't required to provide the documented alignment, then I would agree that Clang should not be assuming this alignment. Supporting malloc replacement is a first-class feature for glibc malloc, Again, this in itself doesn't mean much. You are allowed to replace `malloc`; you are not allowed to replace `malloc` with an incorrect implementation. Presumably we can agree that a replacement that only provided 1-byte alignment would be wrong. The standard for correctness is defined by the platform. If you replaced `malloc` with something that returned 8-byte alignment on Darwin, you would definitely be wrong. So what you need here is a statement from the platform maintainers that it's legal to replace `malloc` with something that provides less alignment than is documented in `man malloc`. Obviously, if you don't actually replace `malloc` and just provide a `jemalloc` symbol, you can do whatever you want. > and related projects avoid relying on alignment guarantees (e.g. libstdc++ > at one point considered assuming that 8-byte allocs were 16-byte aligned, > and decided not to). At least one Linux distribution using clang (Alpine) > uses musl, which is a weak-alignment implementation (contrary to what I > claimed in N2293; I screwed up my background research). > If Alpine Linux wants to provide a weaker alignment guarantee than the "standard" Linux platform, they're entitled to. John.
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
