This is the mail archive of the
mailing list for the GCC project.
Re: Replacing malloc with alloca.
- From: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>, Jeff Law <law at redhat dot com>
- Cc: Ajit Kumar Agarwal <ajit dot kumar dot agarwal at xilinx dot com>, Richard Biener <richard dot guenther at gmail dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Vinod Kathail <vinodk at xilinx dot com>, Shail Aditya Gupta <shailadi at xilinx dot com>, Vidhumouli Hunsigida <vidhum at xilinx dot com>, Nagaraju Mekala <nmekala at xilinx dot com>
- Date: Mon, 14 Sep 2015 09:14:54 +0100
- Subject: Re: Replacing malloc with alloca.
- Authentication-results: sourceware.org; auth=none
- References: <37378DC5BCD0EE48BA4B082E0B55DFAA42990090 at XAP-PVEXMBX02 dot xlnx dot xilinx dot com> <87vbbenpga dot fsf at mid dot deneb dot enyo dot de> <55F5C6E8 dot 5040903 at redhat dot com> <87io7enn34 dot fsf at mid dot deneb dot enyo dot de>
On 13/09/15 20:19, Florian Weimer wrote:
> * Jeff Law:
>> On 09/13/2015 12:28 PM, Florian Weimer wrote:
>>> * Ajit Kumar Agarwal:
>>>> The replacement of malloc with alloca can be done on the following
>>>> If the lifetime of an object does not stretch beyond the immediate
>>>> scope. In such cases the malloc can be replaced with alloca. This
>>>> increases the performance to a great extent.
>>> You also need to make sure that the object is small (less than a page)
>>> and that there is no deep recursion going on. Otherwise, the program
>>> may no longer work after the transformation with real-world restricted
>>> stack sizes. It may even end up with additional security issues.
>> You also have to make sure you're not inside a loop. Even a small
>> allocation inside a loop is problematical from a security standpoint.
>> You also need to look at what other objects might be on the stack and
>> you have to look at the functional scope, not the immediate scope as
>> alloca space isn't returned until the end of a function.
> Ah, right, alloca is unscoped (except when there are variable-length
> Using a VLA might be the better approach (but the size concerns
> remain). Introducing VLAs could alter program behavior in case a
> pre-existing alloca call, leading to premature deallocation.
You also have to consider that code generated for functions containing
alloca calls can also be less efficient than for functions that do not
call it (cannot eliminate frame pointers, for example). So I'm not
convinced this would necessarily be a performance win either.