[tree-ssa] dead const/pure/alloca call removal

[Gabriel Dos Reis]

Jason Merrill <jason@redhat.com> writes:

| On 09 Nov 2003 07:21:30 +0100, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| 
| > Daniel Jacobowitz <drow@mvista.com> writes:
| >
| > [...]
| >
| > | The implementation provides malloc; GCC is merely a part of the
| > | implementation.  We already assume a conforming library for many
| > | optimizations; glibc doesn't provide strlen either.
| >
| > Sure, but isn't a tracing malloc a conforming implementation?
| 
| AFAIK replacing malloc at all is nonconforming.

It would be nonconforming only if GCC provided an implementation for
malloc/free. 

|  It just happens to work on most Unix systems.

This ought to work as currently GCC does not provide an implementation
of malloc.

| > | I disagree that the C standard's definition is too weak to allow
| > | eliding of calls, as-if.  What problems do you see?
| >
| > The as-if would apply *if* GCC is the malloc implementation provider.
| > Currently , it is not,
| 
| That doesn't matter.  GCC can assume the semantics described in the C
| standard unless -fno-builtin.
| 
| Why do you see this as different from strlen?

memory allocation is fundamentally different from counting the number
of characters in a string.  Existing practice is that people provide
their own implementations -- this is permitted partly by the fact that
GCC does not offer a malloc implementation.  
Memory allocation is recognized as so fundamentally different that
even the C++-ish memory allocators are replaceable, i.e. users can
provide their own versions of operator new/operator delete.
Unless, we declare that existing wide-spread practice does not matter,
I would strongly suggest we do not mess with malloc/free.

If speed is what we're after, I think there much more urgent areas to
work on :-)

-- Gaby