<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 16, 2011, at 2:41 PM, John Criswell wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
On 12/16/11 4:14 PM, Chris Lattner wrote:
<blockquote cite="mid:19D8F13C-C5A8-44D3-861A-2CFF72BC2D94@apple.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>
<div>On Dec 16, 2011, at 12:39 PM, Kostya Serebryany wrote:</div>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin-top: 0px;
margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex;
border-left-width: 1px; border-left-color: rgb(204, 204,
204); border-left-style: solid; padding-left: 1ex;
position: static; z-index: auto; ">
<div class="HOEnZb">
<div class="h5">> Do we consider the above
transformation legal?<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
<div><br>
</div>
<div>Yes, the transformation is perfectly legal for the normal
compiler.</div>
</div>
</blockquote>
<br>
So how do you guarantee that the behavior is predictable regardless
of hardware platform if you don't define what the behavior should
be?<br></div></blockquote><div><br></div><div>I'm not sure what you mean. What isn't defined?</div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><blockquote cite="mid:19D8F13C-C5A8-44D3-861A-2CFF72BC2D94@apple.com" type="cite"><div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div class="HOEnZb"><div class="h5">> I would argue that it should not be
legal. We don't actually know what<br>
> comes after the 22 byte object. Is it another
memory object? A<br>
> memory-mapped I/O device? Unmapped memory?
Padded junk space? Reading<br>
> memory-mapped I/O could have nasty side effects,
and accessing unmapped<br>
> memory could cause the program to fault even
though it was written correctly<br>
> as the source-language level.<br>
</div>
</div>
</blockquote>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<br>
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.<br></div></blockquote><div><br></div><div>There is no way for this transformation to introduce a page spanning load.</div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">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?</div></blockquote><div><br></div><div>Yes.</div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">What if you
have a funky architecture that someone is porting LLVM to, or
someone is using x86-32 segments in an interesting way?<br></div></blockquote><div><br></div><div>We'll burn that bridge when we get to it ;-)</div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">Moreover, I don't really understand the rationale for allowing a
transform to introduce undefined behavior into programs that exhibit
no undefined behavior.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>-Chris</div></div><br></body></html>