[llvm-dev] Added AllocaInsts are relocated in stack

[sam djafari via llvm-dev]

Oh, I see. Regarding single stack allocation i am not sure how it is
possible.
For example for each local variable, I need to maintain a 4-byte metadata.
for example, if it is a 4 bytes variable (e.i. int), I need to allocate 8,
or if it is a struct, let's say 26 bytes, I need to allocate 30 bytes.
How it is possible using AllocaInst?

Thanks in advance

On Fri, Sep 21, 2018 at 9:36 AM Tim Northover <t.p.northover at gmail.com>
wrote:

> Hi Sam,
>
> On Fri, 21 Sep 2018 at 14:05, sam djafari <sami.djafari at gmail.com> wrote:
> > Thanks for your reply. However, I have seen that addressSanitizer has
> done this by placing redzones around each local variable.
>
> Maybe conceptually, but as far as I can see from the IR ASAN maintains
> a completely separate stack via calls to runtime support (like
> __asan_stack_malloc).
>
> > By doing so, LLVM would place them in the expected order I guess.
>
> I doubt it. Allocating objects on the stack involves a reasonably
> sophisticated algorithm to try and minimize space consumed. Some of
> that involves reordering variables with different sizes so that
> they're contiguous. Some involves lifetime tracking to try and share
> slots if two variables are live at different points.
>
> Combined, it means LLVM isn't going to make any guarantees that the
> order you write your allocas (or anything else you have access to)
> dictates the order they get laid out in memory.
>
> Why do you think the single-allocation approach isn't appropriate?
> It's really the only way to guarantee you get a block, whether done
> via alloca or via callbacks like ASAN.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180921/32d9c865/attachment.html>