Re: gcc 2.92.2: bad code generation from tail-call optimization (x86)

[Jeffrey A Law <law at cygnus dot com>]

  In message <14443.40523.991206.668791@spleen.hq.tensilica.com>you write:
  > 
  > The included function, when compiled with gcc 2.95.2 generates bad code for
  > x86 because of an incorrectly applied tail-call optimization. The function
  > takes the address of an automatic, and thus should not be a candidate for
  > tail-calls. The source and assembly code are commented to show the location
  > of the incorrect tail-call.
Agreed.


  > We took a quick look into the possible cause, and it appears that the
  > function that implements the optimization in stmt.c:optimize_tail_resursion
  > is using 'frame_offset' before it is calculated.
Not exactly.

More likely we need to scan the insn chain to see if there are any embedded
ADDRESSOF expressions which can turn into stack slots for locals or parms
if we were unable to optimize away the address reference during early
RTL optimizations.


Even if we check for ADDRESSOF expressions in the insn chain, I'm not
100% sure that catches everything.  For example, the tail call itself
might take the address of a local or parm and that wouldn't be exposed as
an ADDRESSOF in the insn chain yet since we haven't expanded the RTL for
the argument setup yet.

Most likely the only good way to get this right is to go ahead and convert
to using the CALL_PLACEHOLDER and build up multiple call sequences, then
commit to one after RTL generation is complete.


jeff