[cpp-threads] Yet another visibility question

[Boehm, Hans]

> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk 
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf 
> Of Lawrence Crowl
> Sent: Tuesday, December 19, 2006 4:14 PM
> To: C++ threads standardisation
> Subject: Re: [cpp-threads] Yet another visibility question
> 
> On 12/19/06, Boehm, Hans <hans.boehm at hp.com> wrote:
> > This does seem to be (barely) implementable, since the load_raw 
> > optimization impact is contained to the function and hence 
> compilation 
> > unit in which it is contained.  But it has several 
> remaining problems.
> > I think the showstopper is that even the first example breaks if I 
> > make the load_raw call in a separate function.  Hence I 
> would expect 
> > it to only work in practice for badly structured code.
> 
> I don't think we can rely on any notion of separate 
> compilation or separate functions.  Inter-procedural and 
> inter-object optimization is sufficiently common so that the 
> compiler will have essentially random visibility.

The problem here is essentially the converse.  If we require
dependencies to enforce ordering, and the dependencies cross compilation
units, then any optimization that touches any part of the chain has to
be careful to preserve the dependencies.  But it has no way of knowing
that without seeing the whole program.  Thus we would essentially be
relying on whole program optimization which, in light of dynamic
libraries, seems even slightly more absurd than precluding it.

To be precise, assume we have (taking some liberties with types)

f1() { f2(x.load_raw()); }
f2(x) {f3(x);}
f3(x) {if (x == 1) f4(1); else f5(1);}
f4(x) {f6(x);}
f5(x) {f6(x);}
f6(x) {y.store_raw(1);}

If I optimize f3, f4, and f5 in isolation, so that f3 just calls f6(1),
as far as most hardware is concerned, I've removed the dependency of the
store on the load.

We can argue about whether this should be considered a real dependency.
But as I argued earlier with Peter, if we assume it isn't, I think
dependency-based ordering becomes largely useless to the programmer,
since I can't reason about it without looking through abstraction
boundaries.  In real life f4 and f5 would be more complicated, but if
they share a common assignment, I potentially lose.

Hans