[PATCH] A new HeapToStack allocation promotion pass
chandlerc at google.com
Tue Sep 24 23:17:56 PDT 2013
On Wed, Sep 25, 2013 at 12:24 AM, Nick Lewycky <nicholas at mxc.ca> wrote:
> Hal Finkel wrote:
>> ----- Original Message -----
>>> On Sep 23, 2013, at 5:00 PM, hfinkel at anl.gov wrote:
>>> This adds a new optimization pass that can 'promote' malloc'd
>>>> memory to stack-allocated memory when the lifetime of the
>>>> allocation can be determined to be bounded by the execution of the
>>> Is this transformation safe in general?
>> This is a good point; I'd not thought about the malloc introspection
>> functions. I think that there are multiple possible viewpoints:
>> 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.
>> 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.
>> I'm open to both views; what do others think?
> 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.
> And indeed, the standards don't quite say this yet,
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).
> but we should be working to fix this. See http://www.open-std.org/jtc1/**
> sc22/wg21/docs/papers/2013/**n3537.html<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3537.html>for C++.
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.
>> Thanks again,
>> Various libc implementations
>>> have functions for getting information about the allocated chunk.
>>> For example, malloc_size(3) on OS X, malloc_usable_size(3) in glibc.
>>> This patch seems to break valid code:
>>> [secdev:~/m] s$ uname -a
>>> Linux secdev 3.8.0-30-generic #44-Ubuntu SMP Thu Aug 22 20:52:24 UTC
>>> 2013 x86_64 x86_64 x86_64 GNU/Linux
>>> [secdev:~/m] s$ cat a.c
>>> int main()
>>> void *p = malloc(10);
>>> size_t s = malloc_usable_size(p);
>>> printf("%zu\n", s);
>>> [secdev:~/m] s$ ../build-master/bin/clang -Wall a.c
>>> [secdev:~/m] s$ ./a.out
>>> [secdev:~/m] s$ ../build-master/bin/clang -Wall a.c -O1
>>> [secdev:~/m] s$ ./a.out
>>> Segmentation fault (core dumped)
>>> Stephen Checkoway
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits