<div class="gmail_quote">On Wed, Jan 25, 2012 at 12:27 AM, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Chandler,<br>
<div class="im"><br>
> On Tue, Jan 24, 2012 at 1:36 PM, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:kcc@google.com">kcc@google.com</a>>> wrote:<br>
><br>
>     ASAN *can* be modified this way (it will actually make instrumentation ~10%<br>
>     cheaper).<br>
>     But this mode will miss some bugs that the current mode finds.<br>
>     I've seen at least a couple of such *real* bugs.<br>
><br>
>     And these bugs are not only about exploitability, but also about correctness.<br>
>     If a program reads garbage, there is no simple way to statically prove that<br>
>     this garbage does not affect the program's behavior.<br>
><br>
><br>
> We could go back to my original proposed fix -- come up with a specific way to<br>
> model a "read past the end" in the LLVM IR. Essentially capture the act of load<br>
> widening in the IR. I'm imagining 'load i8* %ptr as i64'. This is a load that<br>
> reads an i64 value from memory, but only fills the low 8 bits with a value, the<br>
> high bits are undef.<br>
<br>
</div>how about moving the load widening transformation to the code generators<br>
instead (which is in essence where you are moving it)?  Unlike your suggestion,<br>
this would have the disadvantage that you wouldn't get "knock on" improvements<br>
from the transform of the kind that the IR optimizers can do.  But are those<br>
common/significant?<br></blockquote><div><br></div><div>The knock-on improvement that leaps to mind is vectorization. I'd like to be able to load widen enough to merge the load into any vectorized loads going on in the loop. There are probably others though...</div>
<div><br></div><div>FWIW, I don't think my proposal sound all that scary to implement as long as we get the semantics right. We simply cause the majority of existing load instruction interface users' semantics to be preserved, and audit them looking for the ones that need to switch to new interfaces... A good chunk of walking through code, but it should be reasonable to do if someone were interested. If i weren't over-booked right now, I'd volunteer.</div>
</div>