This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] replace malloc with a decl on the stack


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]