[PATCH] A new HeapToStack allocation promotion pass

[Duncan Sands]

Hi Hal,

On 04/10/13 14:38, Hal Finkel wrote:
> ----- Original Message -----
>> (I am not on the list)
>>
>>> 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.
>>>
>>> To be specific, consider the following three cases:
>>>
>>> void bar(int *x);
>>>
>>> void foo1() {
>>>    int *x = malloc(16);
>>>    bar(x);
>>>    free(x);
>>> }
>>>
>>> In this case the malloc can be replaced by an alloca, and the free
>>> removed. Note that this is true even though the pointer 'x' is
>>> definitely
>>> captured (and may be recorded in global storage, etc.).
>>
>> Hello,
>>
>> this seems to rely on the fact that 'bar' returns normally, and thus
>> that
>> whenever malloc is executed, free will be as well. However, bar could
>> never return, or return abnormally by throwing an exception which
>> will
>> skip the call to free.
>>
>> void bar(int *x) {
>>     free(x);
>>     throw 42;
>> }
>>
>> will result in calling free on the stack. Now if there was a
>> destructor
>> calling free in foo1... Do you actually also consider exceptions when
>> you
>> test that all paths from malloc to the exits contain a call to free?
>> That
>> would only leave noreturn functions.
>
> Marc,
>
> Thanks!
>
> My understanding is that the extra control-flow from exception handling should be accounted for by the basic-block successor/predecessor information (because calling a function that might throw uses invoke, and then you see both the regular predecessor and the cleanup block as predecessors). I'll double-check that's correct. Also, you're right, I should check the function's does-not-return attribute also.

a function can never return without having the no-return attribute.  For example:

   void bar(int *x) {
        free(x);
        .. infinite loop ..
    }

This comes up in PR965 too.

Summary: no-return attribute => does not return.  The reverse implication is
false.

Ciao, Duncan.