[PATCH] A new HeapToStack allocation promotion pass

[Nick Lewycky]

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
>>> function.
>>
>> 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, but we should be 
working to fix this. See 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3537.html for C++.

Nick

>
> Thanks again,
> Hal
>
>> 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
>> #include<malloc.h>
>> #include<stdlib.h>
>> #include<stdio.h>
>>
>> int main()
>> {
>>    void *p = malloc(10);
>>    size_t s = malloc_usable_size(p);
>>    printf("%zu\n", s);
>>    free(p);
>> }
>> [secdev:~/m] s$ ../build-master/bin/clang -Wall a.c
>> [secdev:~/m] s$ ./a.out
>> 24
>> [secdev:~/m] s$ ../build-master/bin/clang -Wall a.c -O1
>> [secdev:~/m] s$ ./a.out
>> Segmentation fault (core dumped)
>>
>>
>> --
>> Stephen Checkoway
>>
>>
>>
>>
>>
>>
>