"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
