This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Don't allow sibcalls on nested functions
- 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
- Date: Mon, 28 Apr 2003 12:52:51 +0200
- Subject: 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 -----