<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 12/16/11 4:35 PM, Chris Lattner wrote:
<blockquote
cite="mid:9CCAA043-D55F-4249-BD4D-139D0E1D1379@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>
<div>On Dec 16, 2011, at 2:27 PM, Kostya Serebryany wrote:</div>
<blockquote type="cite">
<div class="gmail_quote">
<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>This is a good question. Would it be possible for
ASan to do its instrumentation earlier? </div>
</div>
</blockquote>
<div><br>
</div>
<div>It would be possible but undesirable. </div>
<div>First, asan blows up the IR and running asan early will
increase the compile-time. </div>
<div>Second, asan greatly benefits from all optimizations
running before it because it needs to instrument less
memory accesses. </div>
<div>It actually benefits from load widening too: in the
test case above asan instruments only one load instead of
two. </div>
</div>
</blockquote>
<div><br>
</div>
<div>You certainly wouldn't want to run asan before
mem2reg/SRoA, but after that, the benefits are probably small.
I'd guess that there is some non-zero value to exposing the
code generated by asan to the optimizer. Have you looked at
that at all?</div>
<br>
<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>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>
</blockquote>
<br>
It seems that another option would be to check that both the
alignment *and* size of the memory object permit safe load-widening
and to not perform it on memory objects such as this 22-byte object.<br>
<br>
Do you think such unsafe cases occur often in practice?<br>
<br>
-- John T.<br>
<br>
<blockquote
cite="mid:9CCAA043-D55F-4249-BD4D-139D0E1D1379@apple.com"
type="cite">
<div><br>
</div>
<div>-Chris</div>
<div><br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</body>
</html>