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


Gabriel Dos Reis <gdr@integrable-solutions.net> 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
malloc/free pairs.

zw


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