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: Don't allow sibcalls on nested functions


Grr, re-sending a message that bounced after 5 days due a local mail agent
configuration problem. Sorry for the confusion and the induced delay.

----- Forwarded message from Olivier Hainque <hainque at act-europe dot fr> -----

From: Olivier Hainque <hainque at act-europe dot fr>
To: Richard Henderson <rth at redhat dot com>,
	Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, gcc-patches at gcc dot gnu dot org
Cc: hainque at act-europe dot fr
Subject: Re: Don't allow sibcalls on nested functions
Date: Wed, 23 Apr 2003 11:32:57 +0200

Richard Henderson wrote:
> On Mon, Apr 21, 2003 at 05:15:48PM -0400, Richard Kenner wrote:
> > +       /* If the called function is nested in the current one, it might
> > +          access some of the caller's arguments, but could clobber them
> > +          beforehand if the argument areas are shared.  */
> 
> Huh?  This doesn't make any sense at all.  When, exactly, 
> are argument areas "shared" between caller and callee?
> 
> "Never" is the condition that comes to mind.

 Catching up email after a couple of days away, so I'll probably need
 to dig a bit before beeing able to provide more detailed info about what
 was exactly happening. Here are a couple of elements, still:

 From direct recollection, the "sharing" issue was related to expand_call:

        /* The argument block when performing a sibling call is the
         incoming argument block.  */
 
 which turned out to be a problem when a nested sibcalled callee tries to
 access it's caller's incoming argument.

 Below is an excerpt of the *preliminary* analysis performed on the testcase
 when the issue first showed up (was on sparc-solaris). I'm just rebuilding
 with the current sources with the patch removed to see if it reproduces.


 > The -O2 -gnatp asm output for histograms.adb shows the problem:
 >
 > histograms__display:
 >         st      %o0, [%sp+68]     <========== (1)
 >
 >         ld      [%o1], %o0
 >         sethi   %hi(...__wrapper_for_check_zoom_factor.2), %g1
 >         jmpl    %g1 + %lo(...__wrapper_for_check_zoom_factor.2), %g0

 > histograms__display__wrapper_for_check_zoom_factor.2:
 >         save    %sp, -120, %sp
 >         st      %i0, [%fp+68]    <========== (4)
 >
 >         call    histograms__display__check_zoom_factor.0, 0


 > The store (1) retrieves the Zoom_Factor argument and places it on the stack.
 ...
 > The store (4) in wrapper_for_... clobbers the value with its input argument.

  Both come from insns like: (set (mem virtual-incoming-args) (reg i0))

  But a sibcall optimization is performed for the call to wrapper_... (see
  that a jmp insn is used), and the two mems end up referencing the same
  location.

 
Olivier

----- End forwarded message -----


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