<div dir="ltr">On Wed, Sep 25, 2013 at 12:24 AM, Nick Lewycky <span dir="ltr"><<a href="mailto:nicholas@mxc.ca" target="_blank" class="cremed">nicholas@mxc.ca</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Hal Finkel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
----- Original Message -----<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sep 23, 2013, at 5:00 PM, <a href="mailto:hfinkel@anl.gov" target="_blank" class="cremed">hfinkel@anl.gov</a> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This adds a new optimization pass that can 'promote' malloc'd<br>
memory to stack-allocated memory when the lifetime of the<br>
allocation can be determined to be bounded by the execution of the<br>
function.<br>
</blockquote>
<br>
Is this transformation safe in general?<br>
</blockquote>
<br>
This is a good point; I'd not thought about the malloc introspection functions. I think that there are multiple possible viewpoints:<br>
<br>
1. Clang/LLVM implement particular standards (C/C++), and according to those standards malloc/free are reserved as part of the implementation. As a result, the compiler is free to implement these functions in any way it sees fit, so long as that mechanism complies with the requirements contained the language specification. The introspection functions are not part of the language specifications, and you cannot expect them to work unless you disable the compiler's understanding of malloc/free: -fno-builtin=malloc (or similar). FWIW, these introspection functions also fail under any setup where an alternate allocator has hooked malloc/free.<br>
<br>
2. Clang/LLVM serve as a compiler that is part of a (conforming) programming environment for the target system. This environment includes the system libraries, specifically including all documented public functions in those libraries. In this view, the 'as if' requirement extends to all side effects of the system-libc-provided function implementations.<br>
<br>
I'm open to both views; what do others think?<br>
</blockquote>
<br></div>
I think what makes most sense and is least surprising is for mallinfo() to return the actual amount of memory allocated, and for the compiler to be allowed to change the amount of memory allocated from what malloc() says. This is a variant that is "mostly #1", and I think it's pragmatic. Nobody wants to prevent the compiler from reducing memory usage if it could, and users of mallinfo() are using it to do things like determine how much memory the program is using so that it doesn't run out of RAM.<br>
<br>
And indeed, the standards don't quite say this yet,</blockquote><div><br></div><div>Actually, for C, the committee claims that it does. I don't really understand their reading of the standard here, but we submitted a paper to make this the specific behavior, and the response was that they believed the wording to permit this today for C (and thus malloc).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> but we should be working to fix this. See <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3537.html" target="_blank" class="cremed">http://www.open-std.org/jtc1/<u></u>sc22/wg21/docs/papers/2013/<u></u>n3537.html</a> for C++.</blockquote>
<div><br></div><div>And for C++, the revision of that paper was voted into the CD for C++14, and is likely to ship in C++14. I would strongly encourage Clang and other implementations to use this interpretation of the standard as an extension in previous standards.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
Nick</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks again,<br>
Hal<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Various libc implementations<br>
have functions for getting information about the allocated chunk.<br>
For example, malloc_size(3) on OS X, malloc_usable_size(3) in glibc.<br>
This patch seems to break valid code:<br>
<br>
[secdev:~/m] s$ uname -a<br>
Linux secdev 3.8.0-30-generic #44-Ubuntu SMP Thu Aug 22 20:52:24 UTC<br>
2013 x86_64 x86_64 x86_64 GNU/Linux<br>
[secdev:~/m] s$ cat a.c<br>
#include<malloc.h><br>
#include<stdlib.h><br>
#include<stdio.h><br>
<br>
int main()<br>
{<br>
void *p = malloc(10);<br>
size_t s = malloc_usable_size(p);<br>
printf("%zu\n", s);<br>
free(p);<br>
}<br>
[secdev:~/m] s$ ../build-master/bin/clang -Wall a.c<br>
[secdev:~/m] s$ ./a.out<br>
24<br>
[secdev:~/m] s$ ../build-master/bin/clang -Wall a.c -O1<br>
[secdev:~/m] s$ ./a.out<br>
Segmentation fault (core dumped)<br>
<br>
<br>
--<br>
Stephen Checkoway<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br></div></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank" class="cremed">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank" class="cremed">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div></div>