[llvm] [Allocator] Keep bump pointer at a minimum alignment (PR #203718)

[Fangrui Song via llvm-commits]

================
@@ -150,30 +161,31 @@ class BumpPtrAllocatorImpl
     // Keep track of how many bytes we've allocated.
     BytesAllocated += Size;
 
-    uintptr_t AlignedPtr = alignAddr(CurPtr, Alignment);
-
     size_t SizeToAllocate = Size;
 #if LLVM_ADDRESS_SANITIZER_BUILD
     // Add trailing bytes as a "red zone" under ASan.
     SizeToAllocate += RedZoneSize;
 #endif
+    SizeToAllocate = alignToPowerOf2(SizeToAllocate, MinAlign);
 
-    uintptr_t AllocEndPtr = AlignedPtr + SizeToAllocate;
-    assert(AllocEndPtr >= uintptr_t(CurPtr) &&
+    // CurPtr is already MinAlign-aligned, so only a stricter request realigns.
+    char *Ptr = CurPtr;
+    if (Alignment.value() > MinAlign)
+      Ptr = reinterpret_cast<char *>(alignAddr(Ptr, Alignment));
----------------
MaskRay wrote:

 No evidence of any AA / CaptureTracking / FunctionAttrs optimization from reimplementing alignAddr with `__builtin_align_up`. There is a minor inline cost difference, though:
```
  - alignAddr via __builtin_align_up makes lld marginally larger (+3472 B .text, +3548 B across 37 functions), not smaller — opposite of the AA hypothesis.
  - The realign instructions are byte-identical (add 0x7; and -0x8); the deltas are pure inlining-decision ripple in StringMap/AllocatorList/yaml::Scanner helpers.
  - Root cause quantified: the inline-cost model rates the ptrmask chain 5 units (one InstrCost) cheaper than add;and — because ptrmask itself is TCC_Basic=1 (fall-through return 1 at TargetTransformInfoImpl.h:966, not in any free list), same as and, but the +(align-1) becomes a free GEP offset instead of a
  charged add. That ±5 nudge tips inlining thresholds, so B inlines slightly more → bigger binary.
```

https://github.com/llvm/llvm-project/pull/203718