[LLVMdev] load widening conflicts with AddressSanitizer

[Chandler Carruth]

On Wed, Jan 25, 2012 at 12:27 AM, Duncan Sands <baldrick at free.fr> wrote:

> Hi Chandler,
>
> > On Tue, Jan 24, 2012 at 1:36 PM, Kostya Serebryany <kcc at google.com
> > <mailto:kcc at google.com>> wrote:
> >
> >     ASAN *can* be modified this way (it will actually make
> instrumentation ~10%
> >     cheaper).
> >     But this mode will miss some bugs that the current mode finds.
> >     I've seen at least a couple of such *real* bugs.
> >
> >     And these bugs are not only about exploitability, but also about
> correctness.
> >     If a program reads garbage, there is no simple way to statically
> prove that
> >     this garbage does not affect the program's behavior.
> >
> >
> > We could go back to my original proposed fix -- come up with a specific
> way to
> > model a "read past the end" in the LLVM IR. Essentially capture the act
> of load
> > widening in the IR. I'm imagining 'load i8* %ptr as i64'. This is a load
> that
> > reads an i64 value from memory, but only fills the low 8 bits with a
> value, the
> > high bits are undef.
>
> how about moving the load widening transformation to the code generators
> instead (which is in essence where you are moving it)?  Unlike your
> suggestion,
> this would have the disadvantage that you wouldn't get "knock on"
> improvements
> from the transform of the kind that the IR optimizers can do.  But are
> those
> common/significant?
>

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...

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120125/3ea6df5d/attachment.html>