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: [tree-ssa] dead const/pure/alloca call removal


> Jan Hubicka <hubicka@ucw.cz> writes:
> 
> > Are you really sure we want to clear alloca too?  It has side effect.
> > Only I know that given the semantic of alloca the side effect is useless
> > when return value is thrown away.
> 
> I don't know what the right thing is, but I'd point out that this
> optimization applies to all functions whose side effect is to allocate
> a new block of memory, the sole pointer to which is returned.  malloc
> and calloc (but not realloc) are the obvious examples.

Malloc/calloc will always have free call paired (unless program is
leaky) so this won't buy us much yet.  We need symetric attribute for
free function and we need to make this part of dominator optimizations
or something like that.
Alloca is easier to be dealt with.
> 
> However, I am a little worried about deleting calls to memory
> allocation functions whose return value is discarded.  People may be
> doing clever things, like using a dummy call to alloca to force extra
> stack alignment.
For enforcing stack alignment, we probably should have better way to do
so.  This is clearly quite dirty.  Have you seen someone doing it?
It would be nice to optimize alloca well and also turn alloca into stack
frame allocation for static block sizes not allocated within loops.

In longer run I would like to see malloc/free pairs marked and
elliminated too.  For C++ programs it is not at all that uncommon to
allocate something just to pass it around and with scalar replacement we
may simply elliminate all needs for the memory location.

I definitly know of at least one C++ compiler able to turn malloc/free
pairs into alloca and alloca into stack allocations getting very
noticeable gains from this on certain cases.

But I can ommit alloca bit from my patch and delay it until we decide
whether we want to do something similar.  For C++ heap allocation this
needs special flag (I believe - not the case of compiler I saw) as it
allows user to redirect allocators into his own implementation. This is
definitly relatively controversal issue.

Honza
> 
> zw


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