This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix problem with late insns in sibcall


On Thu, May 01, 2003 at 06:45:20AM -0400, Richard Kenner wrote:
> You lost me here.  Why can't the above C code occur?

I don't know.  Indeed, trying to reproduce this in C I cannot,
and while looking at why I can't figure out how Ada managed to
make it occur.

Every variant test case I tried resulted in expand_call being
invoked with target==NULL.  In particular because of 

4250      /* If the rhs is a function call and its value is not an aggregate,
4251         call the function before we start to compute the lhs.
4252         This is needed for correct code for cases such as
4253         val = setjmp (buf) on machines where reference to val
4254         requires loading up part of an address in a separate insn.
...
4260      if (TREE_CODE (from) == CALL_EXPR && ! aggregate_value_p (from)

Don't let the name aggregate_value_p fool you like it did me.
It doesn't look at the type to see that it is a RECORD_TYPE,
or anything else.  It looks at hard_function_value to see if
it's returned in registers.

So that takes care of all (interesting) scalar return types,
plus record types that go through registers.

The only other possibility I know of is returning the structure
in memory indirectly via hidden first argument.  In that case,
if we're assigning the whole structure, then the target itself is
passed as the destination.  If we're copying from a temporary,
such as bar().x, then bits inside COMPONENT_REF force target
to be NULL, so again we wind up with code after the call.


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]