[PATCH] D71975: [Support] Support MF_HUGE_HINT on Linux and FreeBSD
Reid Kleckner via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Dec 30 14:25:03 PST 2019
rnk added a subscriber: aganea.
rnk added a comment.
+ at aganea, who added this flag.
> Note that only a little test is added since the allocateMappedMemory interface is already well-tested. It seems difficult to reliably test that we got large pages. I am open to suggestions here (maybe with userfaultfd ?).
At a certain point, this would really be a test for the OS. That's pretty hard. I think this is fine without additional testing.
================
Comment at: llvm/lib/Support/Unix/Memory.inc:79
+int getHugeMmapFlags(unsigned Flags) {
+ if (Flags & llvm::sys::Memory::MF_HUGE_HINT) {
----------------
Prefer static over anon ns:
https://llvm.org/docs/CodingStandards.html#anonymous-namespaces
================
Comment at: llvm/lib/Support/Unix/Memory.inc:169
+ if (PFlags & llvm::sys::Memory::MF_HUGE_HINT)
+ return allocateMappedMemoryImpl(NumBytes, NearBlock,
+ PFlags & ~llvm::sys::Memory::MF_HUGE_HINT,
----------------
This code pattern of a recursive tail call shows up in a few places in old LLVM code like this. Personally, I don't like it. It seems like a do / while loop around the mmap call itself would be clearer, since we don't need to re-run most of the flag calculations above. This would also avoid the Impl rename.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D71975/new/
https://reviews.llvm.org/D71975
More information about the llvm-commits
mailing list