[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