Hi Richard, Is my patch OK?
Thanks. H.J. ---- On Sun, Jul 10, 2011 at 6:14 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Sun, Jul 10, 2011 at 5:48 PM, Richard Henderson <r...@redhat.com> wrote: >> On 07/10/2011 03:01 PM, H.J. Lu wrote: >>> We only want to promote function parameters passed/returned in register. >>> But I can't tell if a value will be passed in register or memory inside of >>> TARGET_FUNCTION_VALUE. So when FOR_RETURN is 1, we don't >>> promote. Even if we don't promote it explicitly, hardware still zero-extends >>> it for us. So it isn't a real issue. >> >> The hardware *usually* zero-extends. It all depends on where the data is >> coming from. Without certainty, i.e. actually representing it properly, >> you're designing a broken ABI. >> >> What you wrote above re T_F_V not being able to tell register or >> memory doesn't make sense. Did you really mean inside >> TARGET_PROMOTE_FUNCTION_MODE? >> And why exactly wouldn't you be able to tell there? Can you not find out >> via a call to ix86_return_in_memory? >> > > TARGET_PROMOTE_FUNCTION_MODE is for passing/returning > value in a register and the documentation says that: > > FOR_RETURN allows to distinguish the promotion of arguments and > return values. If it is `1', a return value is being promoted and > `TARGET_FUNCTION_VALUE' must perform the same promotions done here. > If it is `2', the returned mode should be that of the register in > which an incoming parameter is copied, or the outgoing result is > computed; then the hook should return the same mode as > `promote_mode', though the signedness may be different. > > > But for TARGET_FUNCTION_VALUE, there is no difference for > register and memory. That is why I don't promote when > FOR_RETURN is 1. mmix/mmix.c and rx/rx.c have similar > treatment. >
