[PATCH] Tree SRA and atomicity/volatility

[Richard Guenther]

On 1/24/07, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
> > I would suggest specifying TYPE_VOLATILE on a structure type as matching
> > behavior with TYPE_VOLATILE on a bitfield with the same machine mode.
>
> I don't follow.  TYPE_VOLATILE on a bitfield seems to be the *least*
> well-defined to me.  For a non-bitfield, we all understand what the "natural"
> access to that field or variable should be, so volatile says "always do that
> access".  But what's the "natural" access to a bitfield that we are to
> preserve?

The choice of wording using "bitfield" was wrong then.  Disregard it
and substitute
"integer of the specified mode".

> > So, if you can set TYPE_MODE of the structure to SImode (as in Erics original
> > example) volatile on the strucutre should behave as if it were an SImode
> > bitfield (or integer).
>
> Sure: that's the same as for a scalar.
>
> > So if you can only use BLKmode on the structure it's either invalid
> > or undefined what happens.
>
> I see *all* of these semantics of volatile as undefined from a formal point
> of view.

Sorry - but we lived in an undefined middle-end world for too long.  "Undefined"
doesn't work there.  It is what gives you what we have now - different behavior
than you expect(ed).

>  When you set it on BLKmode, obviously you're asking for less, but
> the generic principle of doing the least changes still applies.  For example,
> a copy of an entire structure should access each byte of memory exactly once
> (which rules out field-by-field copies of structures that contain bitfields).

I'm asking for a specification, for constraints -- if you want to guarantee what
you said you should specify it.  I'm for leaving it as undefined (which is what
we have now).  Like if you have a large "volatile" structure gcc might still
use memcpy to copy it?  The memcpy implementation might touch parts
of the structure twice to, for example, prime the cache.  So I say you cannot
expect anything for structures that don't fit in a machine word.  (Like, forget
TImode on x86 without proper alignment and forcing SSE register loads)

> > This would of course force more "whole aggregate" access than appearantly
> > required by the language, for example forcing read-modify-write cycles for
> > structure component access rather than just forcing whole aggregate access
> > for whole aggregate copy (which doesn't sound too useful on its own).
>
> I don't follow.
>
> I still don't understand why it's necessary or useful to try to define these
> semantics more precisely.  Traditionally, "volatile" has simply meant to do
> as little mucking around with accesses to volatile objects as possible.
> That's also the easiest implementation.  I don't understand what problem you
> are trying to solve.

Eh?  We are currently perfectly conforming to the undefinedness of volatile
on a structure -- yet you want to "fix" our implementation.  I'm
asking for a reason,
and you say you don't want to give me any other than "as little mucking around
with accesses as possible"?  _That_ sounds like a useful definition to adhere
to the Ada language standard requirements of 'atomicity'.

I'll stop arguing with you here - it doesn't make sense.

Richard.