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

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri marked an inline comment as done.
lebedev.ri 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 =
----------------
bondhugula wrote:
> 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!
While yes, we should be doing that, llvm is really too late for this, it must be done in clang, similarly to D73380.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76974