This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] dead const/pure/alloca call removal
Gabriel Dos Reis <firstname.lastname@example.org> writes:
> | At least in C, and presumably in C++ with direct calls to malloc/free.
> Again, that is fine *if* GCC is a whole implementation of the compiler
> plus the library. Currently, it is not. It relies on third party
> libraries, and such libraries might be doing additional things like
> tracing or implement their own view of memory allocation.
I think this is a bit much. malloc's behavior is specified by the
C standard. We already optimize based on assumptions about other
functions that we don't provide, but whose behavior is specified by
the C standard; why should malloc be different?
Now, if all you're saying is there ought to be a switch to turn this
optimization off, in case someone is doing very clever things with
their malloc implementation that make ignoring its return value
meaningful, with that I would agree.
Digressing a bit, I don't think we should optimize malloc/free pairs
where the memory has stack lifetime into alloca, in general, because
blowing out the size of the user's stack has historically been a
problem with explicit use of alloca, never mind compiler-generated
use. In fact, I want to see a mode that does just the opposite --
converts very large alloca requests (or C99 VLA declarations) into