Re: [gimple] assignments to volatile

[Michael Matz <matz@suse.de>]

Hi,

On Tue, 22 Jun 2010, Nathan Sidwell wrote:

> 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 think you're correct.

> I am unsure whether the behaviour Michael would like is dependent on
> optimization level.  I think that would be a very bad thing, btw.

It wouldn't be dependend on the optimization level, that would be 
terrible.  I.e. the "used-by" property would be purely syntactical.

> 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.

Indeed.  Both semantics (re-read or no re-read) will generate some 
surprises, mine has the problem of context dependency, yours for instance 
breaks this identity:
  x = vol = y;
<==>
  vol = y;
  x = vol;

I read the standard as requiring this identity to hold (in particular the 
language about values of assignments not being lvalues is only to disallow 
constructs like "(a = b) = c;").  That is my fundamental problem with your 
approach, that it effectively creates this identity:
  x = y    // as fragment
<==>
  (t = y, x = t, t)  // t a new temporary of the unqualified type of x

Note that I don't think this would be bad semantics, to the contrary (I'm 
not particularly glad about the context dependency that my reading 
implies).  I just don't see it justified in the standard.

> 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.)

I'd rather think that it's not gimplify's job at all to implement volatile 
semantics.  It's rather the frontend which should make sure all reads and 
writes to volatile objects are emitted as specified in the language 
standard.  gimplify then merely shouldn't change the number and kind of 
accesses to volatile objects (neither should any further transformation).

> 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.

I have no problem if we specify that we gimplify assignments as per the 
above second identity.  (I just also think that the C frontend needs 
fixing to emit explicit re-reads).


Ciao,
Michael.