Thanks for the reply. There should be more opportunties for strictly aligned machines. In my example, the structure is a local variable allocated on stack. I don't see why it is marked as BLKmode. Compiler has full freedom to make it aligned and use DImode instead.
Bingfeng > -----Original Message----- > From: Richard Sandiford [mailto:rdsandif...@googlemail.com] > Sent: 16 March 2009 22:14 > To: Bingfeng Mei > Cc: gcc@gcc.gnu.org; Adrian Ashley > Subject: Re: Understand BLKmode and returning structure in register. > > "Bingfeng Mei" <b...@broadcom.com> writes: > > In foo function, compute_record_mode function will set the mode for > > struct COMPLEX as BLKmode partly because STRICT_ALIGNMENT is 1 on my > > target. In TARGET_RETURN_IN_MEMORY hook, I return 1 for BLKmode type > > and 0 otherwise for small size (<8) (like MIPS). Thus, > this structure > > is still returned through memory, which is not very efficient. More > > importantly, ABI is NOT FIXED under such situation. If an assembly > > code programmer writes a function returning a structure. How does he > > know the structure will be treated as BLKmode or otherwise? So he > > doesn't know whether to pass result through memory or register. Do I > > understand correctly? > > Yes. I think having TARGET_RETURN_IN_MEMORY depend on > internal details > like the RTL mode is often seen as an historical mistake. As you say, > the ABI should be defined directly by the type instead. > > Unfortunately, once you start using a mode, it's difficult to stop > using a mode without breaking compatibility. So one of the > main reasons > the MIPS port still uses the mode is because no-one dares touch it. > > Likewise, it's now difficult to change the mode attached to a > structure > (which could potentially make structure accesses more > efficient) without > accidentally breaking someone's ABI. > > > On the other hand, if I return 0 only according to struct > type's size > > regardless BLKmode or not, GCC will produces very inefficient > > code. For example, stack setup code in foo is still > generated even it > > is totally unnecessary. > > Yeah, there's definitely room for improvement here. And as you say, > it's already a problem for MIPS. I think it's just one of > those things > that doesn't occur often enough in critical code for anyone to have > spent time optimising it. > > Richard > >
