Re: Optimizing of explicit temporary storage

[kaih at khms dot westfalen dot de (Kai Henningsen)]

mark@codesourcery.com (Mark Mitchell)  wrote on 11.10.04 in <416B47AA.3010106@codesourcery.com>:

> Richard Guenther wrote:
>
> > Mike Stump wrote:
> >
> >> On Sunday, October 10, 2004, at 07:48  AM, Richard Guenther wrote:
> >>
> >>> Is it legal for a conforming C++ compiler to optimize away storage
> >>> allocation / deallocation?  Like in
> >>>
> >>> #include <new>
> >>>
> >>> void foo(void)
> >>> {
> >>>         int *x = new(std::nothrow) int;
> >>>         delete x;
> >>> }
> >>>
> >>> is it allowed to kill the new and delete statements?  Would it be
> >>> allowed to do this for the throwing version of new, too?
> >>
> >>
> >> The as if rule is fairly powerful...  If the resulting program
> >> behaves as if it had it, then the optimization is allowed.  I don't
> >> think memory consumption is an externally visible effect.  Now, we
> >> might need to do full program analysis to know which new is run, and
> >> to know its semantics; I don't recall if the user is prohibited from
> >> adding semantics to a new replacement function.
> >
> >
> > Well, I was thinking of the traditional
> >
> > struct Vector {
> >    Vector(int size);
> >    Vector operator*(const Vector&);
> >    Vector& operator=(const Vector&);
> >    double *storage;
> > };
> >
> > and doing expressions like
> >
> > Vector a,b,c;
> > a = b*c;
> >
> > where one usually considers using expression templates because of the
> > temporaries.  With loop fusion one could get the speed of the
> > expression template code, but are you allowed to get rid of the
> > temporaries (and their allocated memory), too?
>
> As Mike says, if you can prove that there are no side-effects, then,
> yes, you can.  But, that's in general impossible; even with
> whole-program analysis, you see that "::operator new" calls
> "std::malloc" and "std::malloc" eventually makes a syscall.  I don't
> think any compiler has ever attempted to turn:
>
>   free (malloc (16));
>
> into a no-op, which would be a simpler case.

Any of these cases can, it seems to me, not really be handled well with  
any kind of whole-program analysis.

Instead, what you'd need is to use some sort of language guarantees about  
the behaviour of the allocation functions themselves (new, delete, malloc,  
free) so the decision becomes local.

This is not really different from optimizing, say, the strXXX() functions.  
You don't look at how they are implemented, you look at what the standard  
tells you about what they do.

Assume you had a strange OS where strlen() was a syscall. You could still  
optimize strlen("foo") to 3, as long as you do *not* try to look at how it  
is actually implemented.

MfG Kai