[cpp-threads] pthreads (was: RE: C++ Connections proposal)

[Boehm, Hans]

I tend to look at isolation and combining stores to struct/class
fields separately.  But you are right that they are basically the
same issue, and they interact in examples like this.

My guess is that some compilers might currently perform transformations
like this, but it would be easy to teach them to stop when we teach
them that only adjacent bit-fields can be spuriously rewritten.
And I believe we need to do that anyway.

(I think Alexander, among others, suggested a more liberal policy.
But we haven't found an architecture likely to still be relevant in
2009 on which that's necessary.  And the current proposal makes
life much easier for programmers.  First generation DEC Alphas
seem to be the canonical counterexample, but they're not that
interesting anymore.  And I think the vast majority were
uniprocessors, which we could deal with if we had to.)

Hans

> -----Original Message-----
> From:  Peter Dimov
> Sent: Tuesday, April 26, 2005 12:06 PM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] pthreads (was: RE: C++ Connections 
> proposal)
> 
> 
> I can think of one example where a compiler could (easily?) 
> have decided to 
> do it.
> 
>     a[0] = true;
>     a[1] = true;
>     a[3] = true;
> 
>     if( b[2] ) a[2] = true;
> 
> A compiler may decide to transform this to:
> 
>     bool tmp = a[2];
>     *(uint32*)a = 0x01010101;
>     if( !b[2] ) a[2] = tmp;
> 
> or even (if byte accesses are particularly expensive):
> 
>     uint32 tmp = a;
>     a = 0x01010101;
>     if( (b & 0x0000FF00) == 0 ) a = tmp | 0x01010001;
> 
> (where a and b are shorthands for the uint32 aliasing the arrays.)
> 
> This is similar to the read-modify-write example, but here 
> the compiler can 
> be said to have a legitimate license to modify a[2]. 
> 
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk