Re: [gimple] assignments to volatile

[Richard Guenther <richard dot guenther at gmail dot com>]

On Tue, Jun 22, 2010 at 1:16 PM, Nathan Sidwell <nathan@codesourcery.com> wrote:
> On 06/21/10 13:07, Richard Guenther wrote:
>
>> Hm, TREE_THIS_VOLATILE (TREE_TYPE (*to_p)) should
>> certainly be TREE_THIS_VOLATILE (*to_p), and all this
>> should be done after gimplifying *to_p. ?I think even just
>> before we build the gimple assign/call do
>
> ...
>
> Thanks! ?here's a tested patch that implements it the way you suggest.
>
> Now, as for the semantics we want. ?I disagree with Michael's opinion.
>
> Firstly, C and C++ differ in their std's description of the semantics of an
> expression cast to void (implicitly or explicitly). ?The C std essentially
> says the value is discarded. ?The C++ std specifies that no lvalue to rvalue
> transformation occurs, and it is this transformation that causes an lvalue
> object to be read. ?There was a long discussion about this several years ago
> when I patched G++ to have somewhat more useful semantics (and warnings)
> than it did have. ?That series of patches started when I noticed that in C++
> '(void)*vol_ptr' did not cause a read of the pointed-to object, but it did
> in C. ?The conclusion at that time were that the implemented C semantics
> were what was wanted. ?These were:
> * after an assignment to a volatile, no re-read occurred.
> * a volatile was always read in a void context.
>
> These rules are
> * simple
> * composable
>
> It means that:
>
> ?'*vol_ptr1 = *vol_ptr2 = 0'
> doesn't read *vol_ptr2 and therefore assign an unknown value to *vol_ptr1.
> ?It also doesn't force any ordering on the two assignments to *vol_ptr1 and
> *vol_ptr2 -- just as would be true if things were not volatile.
>
> ?'*vol_ptr1'
> where this is not the lhs of an assignment, will read the volatile object
> being pointed to, regardless of whether we use the value or not.
>
> Notice in those examples that I have statement fragments. ?The semantics are
> the same regardless of the context in which those fragments occur.
>
> IIUC, Michael's desired semantics are
> *) after an assignment, the value is re-read iff the assignment's value is
> used.
> *) a volatile object is not read in a void context.
> *) a volatile sub-expression is read or re-read if the value is used by the
> containing expression [I am unsure if this is Michael's semantics or not,
> please correct me if I'm wrong]
>
> I am unsure whether the behaviour Michael would like is dependent on
> optimization level. ?I think that would be a very bad thing, btw.
>
> I think these lead to confusing code sequences, and are not composable.
> Fundamentally the ambiguity comes from specifying when an assignment's value
> is needed. ?Without even considering data-flow optimizations that could
> determine a value is unused, we have the following:
>
> ?'cond ? (*vol_ptr = v) : other_v;'
>
> The conditional expression has a value, even though it is in a void context.
> Does that mean that the volatile assignment's value is used or not?
> ?Similarly for:
> ?'something, (*vol_ptr = v);'
> or a more complicated variants:
> ?'something, ((vol_ptr = v), something);'
> ?'(something, (vol_ptr = v)), something;'
>
> the problem here is that the behaviour of a sub-expression now depends on
> the context in which it is embedded (and that could be quite deeply
> embedded). ?If we decide that the above examples do not re-read, because the
> value is ultimately not used, we have the ability for the programmer to
> really get confused during debugging. ?For instance, they may rewrite one of
> these as
> ? 'tmp = cond ? (*vol_ptr = v) : other_v;'
> in order to determine the value that was written. ?But now we've changed the
> pattern of accesses to the volatile object. ?(And by in my recent dive into
> gimplify, we'll have a harder patch to write as we need to track want_result
> through more structures than we do at the moment.)
>
> Should whatever semantics we decide upon be implemented by the gimplifier or
> by the front-end? ?I'm not sure, but I do think the gimplifier should
> specify the semantics of volatile accesses, and those semantics should be
> consistent. Currently they are not.

Thanks for the updated patch.  I will review it once we settled
on the desired semantics.

And yes - the front-ends should make the semantic explicit.
I'd like to get rid of MODIFY_EXPR having a value to avoid these
problems and have the frontends lower MODIFY_EXPRs with
a value by using COMPOUND_EXPRs.

Richard.

> nathan
>
> --
> Nathan Sidwell ? ?:: ? http://www.codesourcery.com ? :: ? ? ? ? CodeSourcery
>
>