> From: DJ Delorie <d...@redhat.com>
> Date: Wed, 16 Jun 2010 18:53:54 -0400
A bit of thread hijacking (moving it to gcc@) I'm afraid, but
it's too related to pass up on the opportunity...
> Index: gcc/doc/invoke.texi
> ===================================================================
> --- gcc/doc/invoke.texi (revision 160864)
> +++ gcc/doc/invoke.texi (working copy)
> @@ -17722,12 +17722,38 @@ be thrown between DSOs must be explicitl
> visibility so that the @samp{type_info} nodes will be unified between
> the DSOs.
>
> An overview of these techniques, their benefits and how to use them
> is at @w...@uref{http://gcc.gnu.org/wiki/Visibility}}.
>
> +...@item -fstrict-volatile-bitfields
> +This option should be used if accesses to volatile bitfields (or other
> +structure fields, although the compiler usually honors those types
> +anyway) should use a single access in a mode of the same size as the
> +container's type, aligned to a natural alignment if possible. For
> +example, targets with memory-mapped peripheral registers might require
> +all such accesses to be 16 bits wide; with this flag the user could
> +declare all peripheral bitfields as ``unsigned short'' (assuming short
> +is 16 bits on these targets) to force GCC to use 16 bit accesses
> +instead of, perhaps, a more efficient 32 bit access.
> +
> +If this option is disabled, the compiler will use the most efficient
> +instruction. In the previous example, that might be a 32-bit load
> +instruction, even though that will access bytes that do not contain
> +any portion of the bitfield, or memory-mapped registers unrelated to
> +the one being updated.
> +
> +If the target requires strict alignment, and honoring the container
> +type would require violating this alignment, a warning is issued.
> +However, the access happens as the user requested, under the
> +assumption that the user knows something about the target hardware
> +that GCC is unaware of.
> +
> +The default value of this option is determined by the application binary
> +interface for the target processor.
> +
> @end table
Can we similarly promise or say something for accesses of the
containing struct as a whole?
I.e. "struct io { unsigned int data : 8;
unsigned int data_av : 1; unsigned int this : 7;
unsigned int that : 8; unsigned int other : 8;};"
and whole-struct assignments through "volatile struct io *iop"?
For one, should this option matter there?
For another, can we promise to not split up such an access for
machines where a full-32-bit-word access makes sense?
I'm asking because a bug in SRA once split up a read followed by
a write of a similar struct (too many single-bit fields to serve
as an example) into *four* variously-sized reads and writes, and
intermixed at that, and I got pushback when arguing the
obviousness of the full access being TRT.
brgds, H-P
PS: Right, for a Linux driver, always access through readl/writel.
