[PATCH] D67399: [ARM] Follow AACPS standard for volatile bitfields

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D67399#1664785 <https://reviews.llvm.org/D67399#1664785>, @dnsampaio wrote:

> @ostannard might prove me wrong, but according to the AACPS:
>
>   When a volatile bit-field is written, and its container does not overlap with any non-bit-field member, its
>    container must be read exactly once and written exactly once using the access width appropriate to the
>    type of the container. The two accesses are not atomic.
>
> This rule does not define that the load is done if required. It states that it will be read once. It even gives the example that an increment will always perform two reads and one write, bitwidth agnostic. It writes just after:


While it can be read as "just always read volatile bitfield before overwriting it", i'm not sure that makes any sense.
Why exactly would you want do to that load, if you don't use it's results? What side-effects does it cause?

What it should be saying is: "when you have a bitfield, and you want to update several of it's fields but not all,
first do one read to get the old contents, then merge old-new data, and then perform a single store replacing the entire contents at once".
That is the only sane behavior it can require.

>   Note: Note the volatile access rules apply even when the width and alignment of the bit-field imply that
>    the access could be achieved more efficiently using a narrower type. For a write operation the read must
>    always occur even if the entire contents of the container will be replaced.
> 
> The rationale is to provide a uniform behavior for volatile bitfields independent of their width (as far they do not overlap with non-bitfields).




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67399/new/

https://reviews.llvm.org/D67399