| Message ID | E51D7EE7-D362-4988-98E1-15A7560AB37C@adacore.com |
|---|---|
| State | New |
| Headers | show |
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
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
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
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.
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)