[PATCH] D76974: [Attributor] Make attributor aware of aligned_alloc for heap to stack conversion

Uday Bondhugula via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 31 12:33:20 PDT 2020


bondhugula marked 2 inline comments as done.
bondhugula added inline comments.


================
Comment at: llvm/lib/Transforms/IPO/Attributor.cpp:5033-5040
+      MaybeAlign Alignment;
       Constant *Size;
       if (isCallocLikeFn(MallocCall, TLI)) {
         auto *Num = cast<ConstantInt>(MallocCall->getOperand(0));
         auto *SizeT = cast<ConstantInt>(MallocCall->getOperand(1));
         APInt TotalSize = SizeT->getValue() * Num->getValue();
         Size =
----------------
xbolva00 wrote:
> bondhugula wrote:
> > lebedev.ri wrote:
> > > Hmm, what is the 'default' alignment for alloca?
> > > Even for non-`aligned_alloc`, there's //some// alignment guarantees for the allocation functions..
> > For alloca, by default the target will typically align to sizeof elt type boundary (per LangRef). For alloc functions without alignment args, it's all system dependent. Glibc's malloc will provide alignment in line with the largest primitive (non-vector) type supported on the system which is typically 16 bytes (fp80, fp128 are the largest).
> we could detect if GNU environment (glibc) is used for compilation so I am wondering if we can annotate malloc with such alignment (16B) if isGNU() == true.
Even if it's the GNU env, the 16 byte alignment isn't guaranteed by malloc (although nearly always true on today's systems). It could be 8 bytes on really old ones - I don't know!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76974/new/

https://reviews.llvm.org/D76974





More information about the llvm-commits mailing list