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
