[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