This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: Continue strict-volatile-bitfields fixes
- From: "Joey Ye" <joey dot ye at arm dot com>
- To: "'Thomas Schwinge'" <thomas at codesourcery dot com>, "Bernd Schmidt" <bernds at codesourcery dot com>, "Richard Earnshaw" <Richard dot Earnshaw at arm dot com>
- Cc: "Richard Guenther" <richard dot guenther at gmail dot com>, <dj at redhat dot com>, "GCC Patches" <gcc-patches at gcc dot gnu dot org>, "Mitchell, Mark" <mark_mitchell at mentor dot com>
- Date: Fri, 20 Apr 2012 14:57:06 +0800
- Subject: RE: Continue strict-volatile-bitfields fixes
- References: <4EBD4BCB.4080807@codesourcery.com> <4ED50901.8090300@codesourcery.com> <DC8FF7F4C84BE44B907369AEF21D9D446E5D368C@NA-MBX-04.mgc.mentorg.com> <4F1D72CA.1060908@codesourcery.com> <874nupb2v4.fsf@schwinge.name> <CAFiYyc08w4PGPEgOGAPH0Ag_BBds_1_wLv=R-DnO+j0b7nPycQ@mail.gmail.com> <4F4282AF.7000804@codesourcery.com> <4F428565.1050508@arm.com> <4F42881B.80800@codesourcery.com> <4F436677.9090203@arm.com> <87obqpnj9i.fsf@schwinge.name> <4F8EE84C.20501@arm.com> <4F8EE8E0.6020907@codesourcery.com> <871unjobrq.fsf@schwinge.name>
> -----Original Message-----
> From: Thomas Schwinge [mailto:thomas@codesourcery.com]
> Sent: Friday, April 20, 2012 01:46
> To: Bernd Schmidt; Richard Earnshaw
> Cc: Richard Guenther; Joey Ye; dj@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