> -----Original Message-----
> From: Thomas Schwinge [mailto:tho...@codesourcery.com]
> Sent: Friday, April 20, 2012 01:46
> To: Bernd Schmidt; Richard Earnshaw
> Cc: Richard Guenther; Joey Ye; d...@redhat.com; GCC Patches; Mitchell,
> Mark
> Subject: Re: Continue strict-volatile-bitfields fixes
> That is, for -fno-strict-volatile-bitfields the second instance of
> »common->code« it is a component_ref, whereas for
> -fstrict-volatile-bitfields it is a bit_field_ref. The former will be
> optimized as intended, the latter will not. So, what should be emitted
> in the -fstrict-volatile-bitfields case? A component_ref -- but this
> is
> what Bernd's commit r182545 (for PR51200) changed, I think? Or should
> later optimization stages learn to better deal with a bit_field_ref,
> and
> where would this have to happen?
R182545 does changes compiler behavior for non-volatile bitfields. As shown in
following ARM example.
typedef struct {
unsigned short a:8, b:8;
} BitStruct;
BitStruct bits;
void foo()
{
bits.a=3;
}
compiled with latest trunk which includes r182545
1. -fstrict-volatile-bitfields -O0:
ldrh r2, [r3, #0] @ movhi
movs r1, #3
bfi r2, r1, #0, #8
strh r2, [r3, #0] @ movhi
2. -fno-strict-volatile-bitfields -O0:
movs r2, #3
strb r2, [r3, #0]
3. -fstrict-volatile-bitfields -Os:
movs r2, #3
strb r2, [r3, #0]
compiled without r182545:
4. -fstrict-volatile-bitfields -O0:
movs r2, #3
strb r2, [r3, #0]
Compare 1 to 4, r182545 does change behavior of non-volatile bitfields.
Comparing to 2, 1 miss the opportunity to use field to replace bitfield. But in
3, combine pass merges the bitfield instructions into one instruction.
So r182545 doesn't impact performance with optimization, at least on ARM. Not
sure if this combine always success in all targets.
- Joey
