I can confirm that our target also generate GOOD code for this case. Maybe this is a EABI or target-specific thing, where Struct/union is forced to memory.
Bingfeng Broadcom Uk > -----Original Message----- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On > Behalf Of Andrew Haley > Sent: 04 January 2010 16:08 > To: gcc@gcc.gnu.org > Subject: Re: PowerPC : GCC2 optimises better than GCC4??? > > On 01/04/2010 12:07 PM, Jakub Jelinek wrote: > > On Mon, Jan 04, 2010 at 12:18:50PM +0100, Steven Bosscher wrote: > >>On Mon, Jan 4, 2010 at 12:02 PM, Andrew Haley > <a...@redhat.com> wrote: > >>> This optimization is done by the first RTL cse pass. I > can't understand > >>> why it's not being done for your target. I guess this will need a > >>> powerpc expert. > >> > >> Known bug, see http://gcc.gnu.org/PR22141 > > > > That's unrelated. PR22141 is about (lack of) merging of > adjacent stores of > > constant values into memory, but there are no memory stores > involved here, > > everything is in registers, so PR22141 patch will make zero > difference here. > > > > IMHO we really should have some late tree pass that > converts adjacent > > bitfield operations into integral operations on > non-bitfields (likely with > > alias set of the whole containing aggregate), as at the RTL > level many cases > > are simply too many instructions for combine etc. to > optimize them properly, > > while at the tree level it could be simpler. > > Yabbut, how come RTL cse can handle it in x86_64, but PPC not? > > Andrew. > >
