[PATCH] A new HeapToStack allocation promotion pass

[Chandler Carruth]

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
>>>> 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,


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.


>
>
> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
> ______________________________**_________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/**mailman/listinfo/llvm-commits<http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130925/84ba8cf8/attachment.html>