Don't allow sibcalls on nested functions
Mon Apr 28 10:52:00 GMT 2003
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 <firstname.lastname@example.org> -----
From: Olivier Hainque <email@example.com>
To: Richard Henderson <firstname.lastname@example.org>,
Richard Kenner <email@example.com>, firstname.lastname@example.org
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:
> 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
> 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
----- End forwarded message -----
More information about the Gcc-patches