<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: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>
<br>
<blockquote
cite="mid:19D8F13C-C5A8-44D3-861A-2CFF72BC2D94@apple.com"
type="cite">
<div><br>
<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>
<br>
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? If not, then I don't see why this can't be a
problem with memory allocated at arbitrary alignments. Furthermore,
you're making assumptions about the underlying MMU. 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>
<br>
If load-widening searches back through the def-use chains to check
that the memory is aligned, then fixing the transform to always
perform defined behavior seems easy enough: we check that the alloca
is of the right alignment, and then we boost the allocated size if
necessary. Since we'll never increase the size by more than 8
bytes, this seems reasonable.<br>
<br>
Moreover, I don't really understand the rationale for allowing a
transform to introduce undefined behavior into programs that exhibit
no undefined behavior. It's a source of subtle problems in the
future when architectures change or someone does something
unconventional, and it trips up memory safety tools and static
analysis tools that are working correctly. The only reason I see
for tolerating it is if fixing the problem would be detrimental to
performance. If Kostya or I or someone else fixes load-widening so
that it doesn't introduce undefined behavior, is it going to really
hurt performance?<br>
<br>
-- John T.<br>
<br>
<blockquote
cite="mid:19D8F13C-C5A8-44D3-861A-2CFF72BC2D94@apple.com"
type="cite">
<div><br>
<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">Having the load hit unmapped memory is
impossible on common</div>
</div>
architectures given the alignment we're talking about
here. And if<br>
memory-mapped IO comes after the memory object, the object
itself also<br>
has some sort of unusual semantics, so it should be using
volatile<br>
loads anyway.<br>
</blockquote>
<div><br>
</div>
<div>Would would be the right way to disable load widening
when AddressSanitizer (or SAFECode) is enabled? </div>
</div>
</blockquote>
<br>
</div>
<div>This is a good question. Would it be possible for ASan to do
its instrumentation earlier? I supposed we could add a "do not
widen" metadata hint on load instructions or something like
that.</div>
<div><br>
</div>
<div>-Chris</div>
<div><br>
</div>
<br>
<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>