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

[Gabriel Dos Reis]

Geoff Keating <geoffk@geoffk.org> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > Jason Merrill <jason@redhat.com> writes:
| > | Why do you think it is relevant whether or not GCC provides the
| > | implementation?
| > 
| > If GCC provides the implementation, it can pretend it knows what it does.
| > Currently, as GCC does not provide the implementation, it cannot
| > pretend it knows all the effects of calling malloc.  What it can
| > assume is that the return value, if non-NULL, obeys the non-aliasing
| > requirement. It can't assume about side-effect beyond that property.
| > That matches current parctice.
| 
| Are you saying that GCC *should* provide malloc, just to enable this
| optimization?

more or less.

|  That seems excessive, especially since the optimisation
| under discussion causes malloc to *not* be called.

Ironically, that is precisely why it should provide it.
If I make a call to an extern function, the implementation details of
which GCC has no knowledge about, then it would be an error if GCC
elided that call.  However, it would be fine if GCC knows the
implementation details and acertain that no "replacement" is possible. 

| Or are you saying that this optimisation should be enabled only on
| those systems where we know how malloc behaves and/or that do not let
| the user replace the malloc library?  (Darwin is such a system.)

That is a far better perspective and compromise. It matches my
previous remarks. 

| [However, I can see that providing a malloc library would be helpful.
| It would be nice to be able to execute constructors at compile-time;
| often they have no side-effects other than calling 'new' and setting
| ethe contents of global objects or malloced memory.  But then you need
| to arrange for 'delete' to work once the program is running, so you
| really want information about malloc's internals.]

I won't push it that far, but if you do it I guess I won't complain :-)

-- Gaby