<br><br><div class="gmail_quote">On Fri, Dec 16, 2011 at 3:22 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:reid.kleckner@gmail.com">reid.kleckner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Dec 16, 2011 at 6:08 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div class="gmail_quote">


<div>In this case, we have an array of 22 bytes which is 16-aligned. </div><div>
I suspect that load widening changed the alignment of alloca instruction to make the transformation legal. Right? </div><div>Can we change the load widening algorithm to also change the size of alloca instruction to be dividable by 16? </div>




<div>This will solve the problem, at least the variant I observe now. </div></div></blockquote><br></div></div><div>I believe it is 16-byte aligned based on ABI requirements for x86-64, though you're right that the optimizer will increase alignment in other cases.  In any case, we don't want to increase the size of the object, because that would prevent packing some other data in after it.  For example, a 2-byte aligned 10 byte object can be placed after it in memory if we keep it 22-bytes in size.</div>



</div></blockquote><div><br></div></div><div>ok.</div><div><br></div><div>I wonder if the load widening can attach some metadata to the stack objects, accesses to which it has modified? </div><div>Then asan will increase the alloca size as appropriate (it does it anyway).</div>



<div><br></div></div></blockquote><div><br></div></div><div>This doesn't seem like a general solution.  What if there is some heap allocated buffer proven to be 16 byte aligned, but 22 bytes long?  Load widening may occur, but you won't be able to fudge the size.</div>
</div></blockquote><div><br></div><div>A 16-byte aligned heap buffer of 22 bytes is a very unlikely thing (still possible, so I agree with you)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div></div><div>Why you don't like the idea to disable or restrict the widening when asan is on?</div>


</div></blockquote><div><br></div></div><div>I agree this seems reasonable.</div></div></blockquote><div><br></div><div>Btw, having a flag that would restrict widening will be helpful for tools like Valgrind/Memcheck and Dr.Memory. </div>
<div><br></div><div>Currently, in order to run Valgrind we have to build programs with "gcc -O1 -disable-some-more-stuff" because of a similar issue. </div><div>Valgrind does not catch stack buffer overflows so it only applies to heap. </div>
<div><br></div><div>--kcc </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div>
<br></div><div>Reid</div></font></span></div>
</blockquote></div><br>