[LLVMdev] load widening conflicts with AddressSanitizer

[Chris Lattner]

On Dec 16, 2011, at 2:41 PM, John Criswell wrote:

> On 12/16/11 4:14 PM, Chris Lattner wrote:
>> 
>> On Dec 16, 2011, at 12:39 PM, Kostya Serebryany wrote:
>>> > Do we consider the above transformation legal?
>> 
>> Yes, the transformation is perfectly legal for the normal compiler.
> 
> So how do you guarantee that the behavior is predictable regardless of hardware platform if you don't define what the behavior should be?

I'm not sure what you mean.  What isn't defined?

>>> > I would argue that it should not be legal.  We don't actually know what
>>> > comes after the 22 byte object.  Is it another memory object?  A
>>> > memory-mapped I/O device?  Unmapped memory?  Padded junk space?  Reading
>>> > memory-mapped I/O could have nasty side effects, and accessing unmapped
>>> > memory could cause the program to fault even though it was written correctly
>>> > as the source-language level.
>> 
>> Device memory accesses need to be done with volatile.  This can't cause a paging problem (e.g. causing an additional page fault where none existed before) on systems that use power-of-two sized pages.
> 
> I think people are misunderstanding my point about I/O memory.  I wasn't saying that the alloca is supposed to access I/O memory; I was saying that it is possible for I/O memory to be located contiguously after the memory object should the memory object be the last object on its memory page.

There is no way for this transformation to introduce a page spanning load.

> Now, after thinking about it, I realize why that can't happen if the memory is aligned to a 16-byte boundary on most architectures.  However, does load-widening actually check that the memory is 16-byte aligned?

Yes.

> What if you have a funky architecture that someone is porting LLVM to, or someone is using x86-32 segments in an interesting way?

We'll burn that bridge when we get to it ;-)

> Moreover, I don't really understand the rationale for allowing a transform to introduce undefined behavior into programs that exhibit no undefined behavior.

There is no undefined behavior here.  This is exactly analogous to the code you get for bitfield accesses.  If you have an uninitialized struct and start storing into its fields (to initialize it)  you get a series of "load + mask + or + store" operations.  These are loading and touching "undefined" bits in a completely defined way.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111216/7dae1cfb/attachment.html>