<div dir="ltr">Oh, I see. Regarding single stack allocation i am not sure how it is possible.<div>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. </div><div>How it is possible using AllocaInst?</div><div><br></div><div>Thanks in advance</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 21, 2018 at 9:36 AM Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Sam,<br>
<br>
On Fri, 21 Sep 2018 at 14:05, sam djafari <<a href="mailto:sami.djafari@gmail.com" target="_blank">sami.djafari@gmail.com</a>> wrote:<br>
> Thanks for your reply. However, I have seen that addressSanitizer has done this by placing redzones around each local variable.<br>
<br>
Maybe conceptually, but as far as I can see from the IR ASAN maintains<br>
a completely separate stack via calls to runtime support (like<br>
__asan_stack_malloc).<br>
<br>
> By doing so, LLVM would place them in the expected order I guess.<br>
<br>
I doubt it. Allocating objects on the stack involves a reasonably<br>
sophisticated algorithm to try and minimize space consumed. Some of<br>
that involves reordering variables with different sizes so that<br>
they're contiguous. Some involves lifetime tracking to try and share<br>
slots if two variables are live at different points.<br>
<br>
Combined, it means LLVM isn't going to make any guarantees that the<br>
order you write your allocas (or anything else you have access to)<br>
dictates the order they get laid out in memory.<br>
<br>
Why do you think the single-allocation approach isn't appropriate?<br>
It's really the only way to guarantee you get a block, whether done<br>
via alloca or via callbacks like ASAN.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
</blockquote></div>