This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] replace malloc with a decl on the stack
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Marc Glisse <marc dot glisse at inria dot fr>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 11 Nov 2013 11:48:35 +0100
- Subject: Re: [RFC] replace malloc with a decl on the stack
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1311100140300 dot 4153 at laptop-mg dot saclay dot inria dot fr> <20131111100814 dot GA6574 at domone dot podge> <20131111101905 dot GU27813 at tucnak dot zalov dot cz>
On Mon, Nov 11, 2013 at 11:19:05AM +0100, Jakub Jelinek wrote:
> On Mon, Nov 11, 2013 at 11:08:14AM +0100, OndÅej BÃlka wrote:
> > On Sun, Nov 10, 2013 at 04:27:00PM +0100, Marc Glisse wrote:
> > > I am posting this patch to get some feedback on the approach. The
> > > goal is to replace malloc+free with a stack allocation (a decl
> > > actually) when the size is a small constant.
> > >
> > Why constraint yourself to small sizes. Stack allocation benefits is
> > speed and less memory comsumption due lack of fragmentation.
>
> Because you can hardly predict what the program will have as stack
> requirements in functions you call? In leaf functions sure, you only care
> not to create too large allocations that would go over the stack size,
> but if you call other functions, you usually can't know (at least without
> sufficient IPA analysis, but that is really hard because it is too early)
Which is completely irrelevant. Checking it in run time is easy as in my
prototype which uses a alternative stack so added stack space does not
coun.
> how much stack will it really need (both fixed requirements for non-VLA
> vars on the stack, spill space, function call arguments and other overhead
> and VLAs and also these malloc turned into stack allocation).
This is argument to turn a alloca and VLA to ones that check if there is
enough stack and get space by other means. This can be with same logic
as described above.
> So, if you say have a malloc with corresponding free shortly afterwards
> but some call in between and decide that it is fine to change it into stack
> allocation when it is half the size of the remaining stack space, but then
Of total stack space, also if we use main stack user should enlarge stacks
accordingly.
> two frames down there will be some non-VLA var that needs 3/4 of the old
> remaining stack space, you've turned a correct program into a broken one.
>
> Jakub