Patchwork [RFC] : use cgraph to emit alpha vas trampoline entry point

login
register
mail settings
Submitter Tristan Gingold
Date Dec. 20, 2011, 8:46 a.m.
Message ID <E51D7EE7-D362-4988-98E1-15A7560AB37C@adacore.com>
Download mbox | patch
Permalink /patch/132355/
State New
Headers show

Comments

Tristan Gingold - Dec. 20, 2011, 8:46 a.m.
Hi,

currently alpha/vms backend emits a trampoline entry point for all nested functions.  This is a waste of code space, as although nested functions are very common in Ada, address of nested functions are only seldom taken.

The fact that the address of a function is taken seems only be available in cgraph.  Is it OK to use cgraph in alpha.c ?

Tristan.
Steven Bosscher - Dec. 24, 2011, 7 p.m.
On Tue, Dec 20, 2011 at 9:46 AM, Tristan Gingold <gingold@adacore.com> wrote:
> Hi,
>
> currently alpha/vms backend emits a trampoline entry point for all nested functions.  This is a waste of code space, as although nested functions are very common in Ada, address of nested functions are only seldom taken.
>
> The fact that the address of a function is taken seems only be available in cgraph.  Is it OK to use cgraph in alpha.c ?

Since no-one has answered yet, I'll just toss in my $0.02.
(Hold on to them a bit, they may be worth a million Euro soon :-)

I think that in general you cannot rely on cgraph in the backends,
this has to be analyzed case-by-case. In your case I'm not sure, but I
think it should be OK.

Your patch uses cgraph in alpha_start_function, which is apparently
only used for the target hook ASM_DECLARE_FUNCTION_NAME. This hook is
called from varasm.c:assemble_start_function(), and this is in turn
only called from final.c:rest_of_handle_final() to generate assembly
from RTL, and from cgraphunit.c:assemble_thunk() to output assembly
for MI thunks. AFAICT cgraph should be correct and complete at the
stage when those two functions are called. Therefore your patch should
be OK.

Perhaps Honza can throw in his 0.02h?

Ciao!
Steven
Richard Guenther - Dec. 30, 2011, 2:20 p.m.
On Sat, Dec 24, 2011 at 8:00 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> On Tue, Dec 20, 2011 at 9:46 AM, Tristan Gingold <gingold@adacore.com> wrote:
>> Hi,
>>
>> currently alpha/vms backend emits a trampoline entry point for all nested functions.  This is a waste of code space, as although nested functions are very common in Ada, address of nested functions are only seldom taken.
>>
>> The fact that the address of a function is taken seems only be available in cgraph.  Is it OK to use cgraph in alpha.c ?
>
> Since no-one has answered yet, I'll just toss in my $0.02.
> (Hold on to them a bit, they may be worth a million Euro soon :-)
>
> I think that in general you cannot rely on cgraph in the backends,
> this has to be analyzed case-by-case. In your case I'm not sure, but I
> think it should be OK.
>
> Your patch uses cgraph in alpha_start_function, which is apparently
> only used for the target hook ASM_DECLARE_FUNCTION_NAME. This hook is
> called from varasm.c:assemble_start_function(), and this is in turn
> only called from final.c:rest_of_handle_final() to generate assembly
> from RTL, and from cgraphunit.c:assemble_thunk() to output assembly
> for MI thunks. AFAICT cgraph should be correct and complete at the
> stage when those two functions are called. Therefore your patch should
> be OK.
>
> Perhaps Honza can throw in his 0.02h?

Err - are not _all_ backends using trampolines to represent address-taken
nested functions?  At least I remeber to see them for x86 and plain C
nested functions as well.  So - is this really a target issue?  At the time
the address of a nested fn is taken the C frontend arranges to (dynamically?)
create the trampoline via some builtin.

Richard.

> Ciao!
> Steven
Jakub Jelinek - Dec. 30, 2011, 4:22 p.m.
On Fri, Dec 30, 2011 at 03:20:30PM +0100, Richard Guenther wrote:
> Err - are not _all_ backends using trampolines to represent address-taken
> nested functions?  At least I remeber to see them for x86 and plain C

Targets using function descriptors (powerpc64-*linux*,
powerpc*-*aix*, ia64-*) don't use trampolines.

	Jakub
Tristan Gingold - Jan. 2, 2012, 9:46 a.m.
On Dec 30, 2011, at 3:20 PM, Richard Guenther wrote:

> On Sat, Dec 24, 2011 at 8:00 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>> On Tue, Dec 20, 2011 at 9:46 AM, Tristan Gingold <gingold@adacore.com> wrote:
>>> Hi,
>>> 
>>> currently alpha/vms backend emits a trampoline entry point for all nested functions.  This is a waste of code space, as although nested functions are very common in Ada, address of nested functions are only seldom taken.
>>> 
>>> The fact that the address of a function is taken seems only be available in cgraph.  Is it OK to use cgraph in alpha.c ?
>> 
>> Since no-one has answered yet, I'll just toss in my $0.02.
>> (Hold on to them a bit, they may be worth a million Euro soon :-)
>> 
>> I think that in general you cannot rely on cgraph in the backends,
>> this has to be analyzed case-by-case. In your case I'm not sure, but I
>> think it should be OK.
>> 
>> Your patch uses cgraph in alpha_start_function, which is apparently
>> only used for the target hook ASM_DECLARE_FUNCTION_NAME. This hook is
>> called from varasm.c:assemble_start_function(), and this is in turn
>> only called from final.c:rest_of_handle_final() to generate assembly
>> from RTL, and from cgraphunit.c:assemble_thunk() to output assembly
>> for MI thunks. AFAICT cgraph should be correct and complete at the
>> stage when those two functions are called. Therefore your patch should
>> be OK.
>> 
>> Perhaps Honza can throw in his 0.02h?
> 
> Err - are not _all_ backends using trampolines to represent address-taken
> nested functions?

No.

>  At least I remeber to see them for x86 and plain C
> nested functions as well.  So - is this really a target issue?

Yes.

>  At the time
> the address of a nested fn is taken the C frontend arranges to (dynamically?)
> create the trampoline via some built-in.

Some backends (AIX, ia64, powerpc64-elf, VMS) don't need trampolines at all because they use function descriptors.

Tristan.

Patch

diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index e3976ed..4f59fe8 100644
--- a/gcc/config/alpha/alpha.c
+++ b/gcc/config/alpha/alpha.c
@@ -7936,9 +7936,14 @@  alpha_start_function (FILE *file, const char *fnname,
       && !TYPE_P (DECL_CONTEXT (decl))
       && TREE_CODE (DECL_CONTEXT (decl)) != TRANSLATION_UNIT_DECL)
     {
-      fprintf (file, "%s..tr:\n", fnname);
-      fprintf (file, "\tldq $1,24($27)\n");
-      fprintf (file, "\tldq $27,16($27)\n");
+      struct cgraph_node *node = cgraph_get_node (decl);
+
+      if (node == NULL || node->address_taken)
+       {
+         fprintf (file, "%s..tr:\n", fnname);
+         fprintf (file, "\tldq $1,24($27)\n");
+         fprintf (file, "\tldq $27,16($27)\n");
+       }
     }
 
   if (TARGET_ABI_OPEN_VMS)