Re: [PATCH] Some middle-end improvements for bitfield handling (followup)

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Jul 01, 2004 at 07:35:21AM -0600, Roger Sayle wrote:
> Hmm.  Ok I agree with your erring on the side of caution.  But the
> above looks like a bug in our RTL handling somewhere.  My guess is
> that for some volatile MEMs, we're either not calling force_reg
> somewhere during RTL expansion, or one of the RTL optimizers is
> duplicating a reference to a volatile memory.

The 2 reads are easily explained.
One of them comes from extract_bit_field, which is the read of the bitfield
value from memory.  The other comes from store_bit_field, where it needs to
read the remaining bits.

Let's consider
volatile struct { unsigned int i : 3, j : 29; } b;
void test1 (unsigned int x)
{
  b.j += x;
}
void test2 (unsigned int x)
{
  b.j = b.j + x;
}
void test3 (unsigned int x)
{
  unsigned int y = b.j;
  y += x;
  b.j = y;
}
void test4 (unsigned int x)
{
  unsigned int y = b.j;
  y = (y << 4 + 32) + x;
  b.j = y;
}
void test5 (unsigned int x)
{
  unsigned int y = foo (b.j, x);
  b.j = y;
}
Are you suggesting that some of these are guaranteed to have just one
read and one write while others use 2 reads and one write?
I believe test1, test2 and test3 will look the same to the expander,
but guaranteeing 1 read for test4, especially if the statements in between
are long and complex is really hard and certainly incorrect for test5.

	Jakub