Re: Computation and usage of SSA_NAME_PTR_INFO
On Wed, May 1, 2013 at 5:11 PM, Nikhil Patil wrote: > On Tue, Apr 30, 2013 at 1:32 PM, Richard Biener > wrote: >> On Mon, Apr 29, 2013 at 7:34 PM, Nikhil Patil >> wrote: >>> Hello, >>> >>> 1. Which passes of gcc make use of points-to information in >>> SSA_NAME_PTR_INFO (or more precisely, pt_solution) in doing >>> optimizations? >> >> All passes that query the alias oracle (tree-ssa-alias.h) which is almost >> all passes doing optimization of memory accesses. > > Thanks a lot for giving direction. I will try finding the passes. > >> >>> >>> 2. Also, who computes this points-to information and populates >>> pt_solution? Is it ONLY ipa-pta pass? >> >> It is points-to analysis, both the IPA variant and the local variant >> (ealias and alias >> passes). > > From what I could understand, gimple passes "pass_build_ealias" > (ealias) and "pass_build_alias" (alias) flags "TODO_rebuild_alias" at > end and then function "execute_function_todo" from passes.c calls > "compute_may_aliases ()" which eventually computes points-to > information. Correct. > Then the IPA PTA pass finds a more precise points-to information. > Please correct if I am wrong. Well. The IPA PTA pass is supposed to compute a points-to solution for the whole translation unit, thus it should be more precise. Due to limitations and bugs in IPA PTA the result does not necessarily have to be more precise. I do not consider the current IPA PTA code production ready (it does not scale very well and it doesn't result in any performance improvements for SPEC 2k6). It's a long-time item on my personal TODO list to at least address the fundamental problems with the current implementation (read: bugs). But my TODO list is quite crowded ... Richard. >> >>> When I accessed pt_solution through a plugin which REPLACES ipa-pta >>> pass, I found that the information (in pt_solution) with and without >>> ipa-pta pass differs only in terms of flags in pt_solution. Here with >>> the examples I could construct, I found that the bitmap 'vars' in >>> pt_solution is same for both the cases. Is it always true? >> >> In theory IPA PTA should be able to compute a more precise solution, >> thus have different (less) bits set in 'vars'. There are several testcases >> that show this, look for ipa-pta* testcases in gcc/testsuite/ >> >> Richard. >> >>> Can someone please help in clarifying these doubts. >>> >>> Thanks in advance. >>> >>> -- >>> Regards, >>> Nikhil Patil. > > -- > Regards, > Nikhil Patil.
Improve hash_table
I am facing several issues with the current hash_table API while
trying to improve what is currently the scev_info_hash_table_type
in tree-scalar-evolution.c. The issues with that hashtable are
1) it allocates GC memory for the entries but their lifetime
is short (call of instantiate_scev / resolve_mixers)
2) it performs too many allocation calls
the hashtable is used to both guard against recursion and to
cache already computed results for visited SSA names.
Ideally we'd have a SSA name -> computed result map here,
but a hash_table and storing just the result there
doesn't work as we cannot recover 'name' from it. Simply
moving the entries from GC memory to heap to address 1)
worsens 2) as heap allocations have a larger overhead than
GC allocations. Thus, in trying to address 2) we'd ideally
want to store the small { name, chrec } pair into the
hashtable itself - but that's unfortunately not possible.
So to make the number of allocations log (N) (as it's
for the hashtable itself) I'm using a vec<{name, chrec}>
as storage and store indexes into that vector in the
hash-table (thus, hashing SSA name -> vector index)
(see patch below). That turns up the issue that
hash_table still will have uintptr_t *
as elements and thus either require external storage
for the indexes or reinterpret_cast<>s all over the place
(as in the patch). Also both the hash and compare
functions are static and have no way to get at the
'storage' vector - thus I need a global variable to
communicate that to them ...
Now, to me the solution seems to be to enhance hash_table
itself to allow embedding the storage - thus not indirect
value_type in hash_table_control but do
template
struct hash_table_control
{
/* Table itself. */
T *entries;
instead. Which requires the controlling traits to provide
an abstraction for HTAB_DELETED_ENTRY and a HTAB_ENTRY_ENTRY.
Simple values in an enum won't do, thus something like
bool empty_value_p (value_type &);
void construct_empty_value (value_type &);
bool deleted_value_p (value_type &);
void construct_deleted_value (value_type &);
would be required. That complicates the traits somewhat
so I wonder if we can use some tricks to allow an optional
typedef <...> slot_type;
that, when available triggers the requirement of the above
abstractions and otherwise uses a default provider with
just
typedef value_type *slot_type;
If I were to implement this I'd probably try to use SFINAE
here and wrap uses of the traits type in hash_table like
template class Allocator = xcallocator>
class hash_table
{
...
hash_table_control ::slot_type> *htab;
and have
template
struct has_slot_type
{
char test (typename Descritpor::slot_type *);
int test (...);
enum { value = sizeof(test(0) == sizeof (char) };
};
template
struct slot_traits_impl;
template
struct slot_traits_impl
{
typedef typename Descriptor::value_type *slot_type;
...
};
template
struct slot_traits_impl
{
typedef typename Descriptor::slot_type slot_type;
...
};
template
struct slot_traits : slot_traits_impl ::value>
{
...
with appropriate deleted/empty entry implementations and forwarding.
Can you think of a simpler way? Would you do it entirely different?
Thanks,
Richard.
Index: gcc/tree-scalar-evolution.c
===
--- gcc/tree-scalar-evolution.c (revision 198441)
+++ gcc/tree-scalar-evolution.c (working copy)
@@ -319,9 +319,11 @@ new_scev_info_str (basic_block instantia
/* Computes a hash function for database element ELT. */
static inline hashval_t
-hash_scev_info (const void *elt)
+hash_scev_info (const void *elt_)
{
- return SSA_NAME_VERSION (((const struct scev_info_str *) elt)->var);
+ const struct scev_info_str *elt = (const struct scev_info_str *) elt_;
+ return iterative_hash_hashval_t (SSA_NAME_VERSION (elt->var),
+ elt->instantiated_below->index);
}
/* Compares database elements E1 and E2. */
@@ -344,38 +346,6 @@ del_scev_info (void *e)
ggc_free (e);
}
-/* Hashtable helpers. */
-
-struct scev_info_hasher
-{
- typedef scev_info_str value_type;
- typedef scev_info_str compare_type;
- static inline hashval_t hash (const value_type *);
- static inline bool equal (const value_type *, const compare_type *);
- static inline void remove (value_type *);
-};
-
-inline hashval_t
-scev_info_hasher::hash (const value_type *elt)
-{
- return hash_scev_info (elt);
-}
-
-inline bool
-scev_info_hasher::equal (const value_type *elt1, const compare_type *elt2)
-{
- return eq_scev_info (elt1, elt2);
-}
-
-/* Deletes database element E. */
-
-inline void
-scev_info_hasher::remove (value_type *e)
-{
- del_scev_info (e);
-}
-
-typedef hash_table scev_info_hash_table_type;
/* Get the scalar evolution of VAR for INSTANTIATED_BELOW basic block.
A first query on VAR returns chrec_not_analyzed_yet. */
@@ -2078,43 +2048,87 @@ analyze_scalar_evolution_in_loop (struct
}
}
Why include header file in for FreeBSD >= 5 ?
Hello, I'm figuring out the code in /usr/lib/gcc/x86_64-redhat-linux/4.1.1/include/stddef.h, and I saw the macro switch below: #if defined (__FreeBSD__) && (__FreeBSD__ >= 5) #include #endif I have gone through all the 、 and source files for the whole 5.X.X version of FreeBSD, and still can't find anything may affect the behavior of code below that macro switch in . Can someone please help in figuring out this ? Thanks in advance. -- Zachary
Re: Identifying global state within GCC
On 05/01/2013 02:32 PM, David Malcolm wrote: I had a go at writing a custom pass to try to locate places where GCC makes use of global state. You can see the pass here (which I implemented using gcc-python-plugin): https://gcc-python-plugin.readthedocs.org/en/latest/working-with-c.html#finding-global-variables A build log from recompiling gcc using this pass can be seen at: http://fedorapeople.org/~dmalcolm/gcc/2013-05-01/make.log (about 12MB in size; I killed it when I saw that stage 1 was done). I'm sure there are quite a few false positives in there. Hope this is helpful. FWIW I had an earlier version of the pass which merely gave *declaration* sites for global variables, rather than all *uses* of such variables. I wonder how useful it would be to filter out the source line information, then produce a histogram of which global state is hit the most often across the build. That'd give us an interesting hitlist as we start trying to remove the global state. jeff
Re: Computation and usage of SSA_NAME_PTR_INFO
On Thu, May 2, 2013 at 1:16 PM, Richard Biener wrote: > On Wed, May 1, 2013 at 5:11 PM, Nikhil Patil > wrote: >> On Tue, Apr 30, 2013 at 1:32 PM, Richard Biener >> wrote: >>> On Mon, Apr 29, 2013 at 7:34 PM, Nikhil Patil >>> wrote: Hello, 1. Which passes of gcc make use of points-to information in SSA_NAME_PTR_INFO (or more precisely, pt_solution) in doing optimizations? >>> >>> All passes that query the alias oracle (tree-ssa-alias.h) which is almost >>> all passes doing optimization of memory accesses. >> >> Thanks a lot for giving direction. I will try finding the passes. >> >>> 2. Also, who computes this points-to information and populates pt_solution? Is it ONLY ipa-pta pass? >>> >>> It is points-to analysis, both the IPA variant and the local variant >>> (ealias and alias >>> passes). >> >> From what I could understand, gimple passes "pass_build_ealias" >> (ealias) and "pass_build_alias" (alias) flags "TODO_rebuild_alias" at >> end and then function "execute_function_todo" from passes.c calls >> "compute_may_aliases ()" which eventually computes points-to >> information. > > Correct. > >> Then the IPA PTA pass finds a more precise points-to information. >> Please correct if I am wrong. > > Well. The IPA PTA pass is supposed to compute a points-to solution > for the whole translation unit, thus it should be more precise. Due to > limitations and bugs in IPA PTA the result does not necessarily have to > be more precise. > > I do not consider the current IPA PTA code production ready (it does > not scale very well and it doesn't result in any performance improvements > for SPEC 2k6). > > It's a long-time item on my personal TODO list to at least address the > fundamental problems with the current implementation (read: bugs). > But my TODO list is quite crowded ... Thanks a lot. The discussion gave me a more insight into the topic and solved my doubts. > > Richard. > >>> When I accessed pt_solution through a plugin which REPLACES ipa-pta pass, I found that the information (in pt_solution) with and without ipa-pta pass differs only in terms of flags in pt_solution. Here with the examples I could construct, I found that the bitmap 'vars' in pt_solution is same for both the cases. Is it always true? >>> >>> In theory IPA PTA should be able to compute a more precise solution, >>> thus have different (less) bits set in 'vars'. There are several testcases >>> that show this, look for ipa-pta* testcases in gcc/testsuite/ >>> >>> Richard. >>> Can someone please help in clarifying these doubts. Thanks in advance. -- Regards, Nikhil Patil. >> >> -- >> Regards, >> Nikhil Patil. -- Regards, Nikhil Patil.
Re: Identifying global state within GCC
On Thu, 2013-05-02 at 12:38 -0400, David Malcolm wrote: > On Thu, 2013-05-02 at 07:20 -0600, Jeff Law wrote: > > On 05/01/2013 02:32 PM, David Malcolm wrote: > > > I had a go at writing a custom pass to try to locate places where GCC > > > makes use of global state. > > > > > > You can see the pass here (which I implemented using gcc-python-plugin): > > > https://gcc-python-plugin.readthedocs.org/en/latest/working-with-c.html#finding-global-variables > > > > > > A build log from recompiling gcc using this pass can be seen at: > > > http://fedorapeople.org/~dmalcolm/gcc/2013-05-01/make.log > > > (about 12MB in size; I killed it when I saw that stage 1 was done). > > > > > > I'm sure there are quite a few false positives in there. > > > > > > Hope this is helpful. FWIW I had an earlier version of the pass which > > > merely gave *declaration* sites for global variables, rather than all > > > *uses* of such variables. > > I wonder how useful it would be to filter out the source line > > information, then produce a histogram of which global state is hit the > > most often across the build. That'd give us an interesting hitlist as > > we start trying to remove the global state. > > A python script to do this (by parsing the logs) can be seen at: > http://fedorapeople.org/~dmalcolm/gcc/2013-05-02/make-histogram.py > > The results of running it can be seen at: > http://fedorapeople.org/~dmalcolm/gcc/2013-05-02/histogram.txt > (141k) [sorry for also sending the large attachment; I rewrote the email and meant to detach both attachments]
naked function attribute support for Mips
This issue of naked function attribute support for Mips has come up in the context of LLVM and in regards to maintaining compatibility with gcc. It's my understanding that the idea of the naked function attribute was rejected for gcc Mips. I'm curious as to why. For LLVM it basically works just by nature of how LLVM works in its target independent part. It will not emit the function prologue or epilogue. It still emits the .frame, .mask and .fmask because that is Mips specific code that does not currently know about the naked function attribute, but that is a separate issue. There is also the issue of the return statement but this also a separate non Mips specific issue and I will post that separately. Tia. Reed
gcc-4.8-20130502 is now available
Snapshot gcc-4.8-20130502 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130502/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 198563 You'll find: gcc-4.8-20130502.tar.bz2 Complete GCC MD5=672a1ad73f8391c5a6b3c4429eb0d798 SHA1=34c5d8813327169d669c93a074a7f5611a30c2fd Diffs from 4.8-20130425 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
return statement in a function with the naked attribute
Should a return statement be emitted in a function that has the naked attribute. There seems to be some confusion here and apparently disagreement between various gcc compilers.
Re: return statement in a function with the naked attribute
On 05/02/2013 03:44 PM, reed kotler wrote: Should a return statement be emitted in a function that has the naked attribute. There seems to be some confusion here and apparently disagreement between various gcc compilers. Sorry. This was meant to be a question. Should a return statement be emitted in a function that has the naked attribute? Tia. Reed
Re: naked function attribute support for Mips
On Thu, May 2, 2013 at 3:35 PM, reed kotler wrote: > This issue of naked function attribute support for Mips has come up in the > context of LLVM and in regards to maintaining compatibility with gcc. > > It's my understanding that the idea of the naked function attribute was > rejected for gcc Mips. > > I'm curious as to why. > > For LLVM it basically works just by nature of how LLVM works in its target > independent part. > > It will not emit the function prologue or epilogue. > > It still emits the .frame, .mask and .fmask because that is Mips specific > code that does not currently know about the naked function attribute, but > that is a separate issue. > > There is also the issue of the return statement but this also a separate non > Mips specific issue and I will post that separately. What are the use cases of naked for mips that the interrupt attribute does not handle? Including the use_shadow_register_set, keep_interrupts_masked and use_debug_exception_return attributes which MIPS backend already handles. Thanks, Andrew Pinski
Re: return statement in a function with the naked attribute
On Thu, May 2, 2013 at 3:46 PM, reed kotler wrote: > On 05/02/2013 03:44 PM, reed kotler wrote: >> >> Should a return statement be emitted in a function that has the naked >> attribute. >> >> There seems to be some confusion here and apparently disagreement between >> various >> gcc compilers. >> > Sorry. This was meant to be a question. > > Should a return statement be emitted in a function that has the naked > attribute? I don't see why there is any confusion about this for interrupt handlers on MIPS (the interrupt attribute being used here). They either use eret or deret which is controlled by the use of the use_debug_exception_return attribute. Thanks, Andrew Pinski > > Tia. > > Reed >
Re: naked function attribute support for Mips
On 05/02/2013 04:13 PM, Andrew Pinski wrote: On Thu, May 2, 2013 at 3:35 PM, reed kotler wrote: This issue of naked function attribute support for Mips has come up in the context of LLVM and in regards to maintaining compatibility with gcc. It's my understanding that the idea of the naked function attribute was rejected for gcc Mips. I'm curious as to why. For LLVM it basically works just by nature of how LLVM works in its target independent part. It will not emit the function prologue or epilogue. It still emits the .frame, .mask and .fmask because that is Mips specific code that does not currently know about the naked function attribute, but that is a separate issue. There is also the issue of the return statement but this also a separate non Mips specific issue and I will post that separately. What are the use cases of naked for mips that the interrupt attribute does not handle? Including the use_shadow_register_set, keep_interrupts_masked and use_debug_exception_return attributes which MIPS backend already handles. Thanks, Andrew Pinski For me, the reason would be so that you can control what is in the function more precisely. This would be for whatever reason you might not want default behavior from some other attribute.
Re: return statement in a function with the naked attribute
On 05/02/2013 04:16 PM, Andrew Pinski wrote: On Thu, May 2, 2013 at 3:46 PM, reed kotler wrote: On 05/02/2013 03:44 PM, reed kotler wrote: Should a return statement be emitted in a function that has the naked attribute. There seems to be some confusion here and apparently disagreement between various gcc compilers. Sorry. This was meant to be a question. Should a return statement be emitted in a function that has the naked attribute? I don't see why there is any confusion about this for interrupt handlers on MIPS (the interrupt attribute being used here). They either use eret or deret which is controlled by the use of the use_debug_exception_return attribute. This is not a Mips specific question. It's a general question about the naked attribute for functions. Should a return statement be emitted in a function that has the naked attribute? Thanks, Andrew Pinski Tia. Reed
Re: return statement in a function with the naked attribute
On Thu, May 2, 2013 at 3:44 PM, reed kotler wrote: > Should a return statement be emitted in a function that has the naked > attribute. I vote yes. > There seems to be some confusion here and apparently disagreement between > various > gcc compilers. Which targets do not generate a return instruction for a naked function? Ian
Re: return statement in a function with the naked attribute
2013/5/3 reed kotler : > Should a return statement be emitted in a function that has the naked > attribute. > > There seems to be some confusion here and apparently disagreement between > various > gcc compilers. > IMHO, it depends on how you define the word 'naked' for a function and how you expect one writing functions with 'naked' attribute. If you think one is supposed to have *complete* control in the function (i.e. only inline assembly code, without using any C statement and variables), then the asm 'ret' can be omitted. Porgrammers must explicitly emit 'ret' in the inline asm. If you allow user using C statement in the function with 'naked' attribute, the asm 'ret' is still required. Because compiler may produce a branch to the epilogue position where 'ret' is expected to exist. AFAIK, there is no standard defining what 'naked' behavior should be. So gcc leaves it to back-end developers. Best regards, jasonwucj
Re: Why include header file in for FreeBSD >= 5 ?
On Thu, May 2, 2013 at 3:32 AM, Zachary Jude wrote: > > I'm figuring out the code in > > /usr/lib/gcc/x86_64-redhat-linux/4.1.1/include/stddef.h, > > and I saw the macro switch below: > > #if defined (__FreeBSD__) && (__FreeBSD__ >= 5) > #include > #endif > > I have gone through all the 、 and > source files for the whole 5.X.X version of > FreeBSD, and still can't find anything may affect the behavior of code > below that macro switch in . > > Can someone please help in figuring out this ? I'm sure you are aware that 4.1.1 is quite old at this point. That code was added by this patch: http://gcc.gnu.org/ml/gcc-patches/2002-10/msg3.html . Perhaps that will help explain what is going on here. Ian
Re: return statement in a function with the naked attribute
On 05/02/2013 07:54 PM, Ian Lance Taylor wrote: On Thu, May 2, 2013 at 3:44 PM, reed kotler wrote: Should a return statement be emitted in a function that has the naked attribute. I vote yes. why would you want that? naked functions are just inline asm. you can generate your own return statement. I meant to end that statement with a question mark. :) There seems to be some confusion here and apparently disagreement between various gcc compilers. Which targets do not generate a return instruction for a naked function? I don't think that any that support naked functions emit a return instruction. Ian
Re: naked function attribute support for Mips
2013/5/3 reed kotler :
> This issue of naked function attribute support for Mips has come up in the
> context of LLVM and in regards to maintaining compatibility with gcc.
>
> It's my understanding that the idea of the naked function attribute was
> rejected for gcc Mips.
>
> I'm curious as to why.
Because there is no 'naked' attribute spec for mips porting in gcc.
Refer to gcc/config/mips/mips.c:
668 static const struct attribute_spec mips_attribute_table[] = {
669 /* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler,
670om_diagnostic } */
671 { "long_call", 0, 0, false, true, true, NULL, false },
672 { "far", 0, 0, false, true, true, NULL, false },
673 { "near",0, 0, false, true, true, NULL, false },
674 /* We would really like to treat "mips16" and "nomips16" as type
675 attributes, but GCC doesn't provide the hooks we need to support
676 the right conversion rules. As declaration attributes, they affect
677 code generation but don't carry other semantics. */
678 { "mips16", 0, 0, true, false, false, NULL, false },
679 { "nomips16",0, 0, true, false, false, NULL, false },
680 { "micromips", 0, 0, true, false, false, NULL, false },
681 { "nomicromips", 0, 0, true, false, false, NULL, false },
682 { "nocompression", 0, 0, true, false, false, NULL, false },
683 /* Allow functions to be specified as interrupt handlers */
684 { "interrupt", 0, 0, false, true, true, NULL, false },
685 { "use_shadow_register_set", 0, 0, false, true, true, NULL, false },
686 { "keep_interrupts_masked", 0, 0, false, true, true, NULL, false },
687 { "use_debug_exception_return", 0, 0, false, true, true, NULL, false },
688 { NULL, 0, 0, false, false, false, NULL, false }
689 };
Generally, 'naked' attribute is used for interrupt handler
because we don't want compiler to generate prologue/epilogue.
Since mips already provides attributes to handle interrupt handler,
it is trivial to have 'naked' one.
Or do you think 'naked' is still useful for some other cases in mips porting?
You can implement it and submit the patch to gcc-patc...@gcc.gnu.org
and I believe the mips maintainers are willing to have review with you. :)
Best regards,
jasonwucj
>
> For LLVM it basically works just by nature of how LLVM works in its target
> independent part.
>
> It will not emit the function prologue or epilogue.
>
> It still emits the .frame, .mask and .fmask because that is Mips specific
> code that does not currently know about the naked function attribute, but
> that is a separate issue.
>
> There is also the issue of the return statement but this also a separate non
> Mips specific issue and I will post that separately.
>
> Tia.
>
> Reed
>
>
>
Re: return statement in a function with the naked attribute
On 05/02/2013 08:41 PM, Chung-Ju Wu wrote: 2013/5/3 reed kotler : Should a return statement be emitted in a function that has the naked attribute. There seems to be some confusion here and apparently disagreement between various gcc compilers. IMHO, it depends on how you define the word 'naked' for a function and how you expect one writing functions with 'naked' attribute. If you think one is supposed to have *complete* control in the function (i.e. only inline assembly code, without using any C statement and variables), then the asm 'ret' can be omitted. Porgrammers must explicitly emit 'ret' in the inline asm. If you allow user using C statement in the function with 'naked' attribute, the asm 'ret' is still required. Because compiler may produce a branch to the epilogue position where 'ret' is expected to exist. AFAIK, there is no standard defining what 'naked' behavior should be. So gcc leaves it to back-end developers. Best regards, jasonwucj I think that the compiler should respect any return statements you explicitly enter, but should not create any that are implied as in reaching the end of the function.
Re: return statement in a function with the naked attribute
On Thu, May 2, 2013 at 8:59 PM, reed kotler wrote: > On 05/02/2013 07:54 PM, Ian Lance Taylor wrote: >> >> On Thu, May 2, 2013 at 3:44 PM, reed kotler wrote: >>> >>> Should a return statement be emitted in a function that has the naked >>> attribute. >> >> I vote yes. > > why would you want that? naked functions are just inline asm. > you can generate your own return statement. > > I meant to end that statement with a question mark. :) > >>> There seems to be some confusion here and apparently disagreement between >>> various >>> gcc compilers. >> >> Which targets do not generate a return instruction for a naked function? > > I don't think that any that support naked functions emit a return > instruction. Well, if they all agree, then clearly that is what we should do. But you said there was some confusion. To what were you referring? Ian
Re: return statement in a function with the naked attribute
On 05/02/2013 09:06 PM, Ian Lance Taylor wrote: On Thu, May 2, 2013 at 8:59 PM, reed kotler wrote: On 05/02/2013 07:54 PM, Ian Lance Taylor wrote: On Thu, May 2, 2013 at 3:44 PM, reed kotler wrote: Should a return statement be emitted in a function that has the naked attribute. I vote yes. why would you want that? naked functions are just inline asm. you can generate your own return statement. I meant to end that statement with a question mark. :) There seems to be some confusion here and apparently disagreement between various gcc compilers. Which targets do not generate a return instruction for a naked function? I don't think that any that support naked functions emit a return instruction. Well, if they all agree, then clearly that is what we should do. But you said there was some confusion. To what were you referring? Ian There was some confusion on the llvm list because some tests were run on targets that did not support the naked attribute. I think we are thinking now that the return statement should not be emitted unless explicitly requested. It's not totally clear in the gcc manual so that is why I was asking.
Re: return statement in a function with the naked attribute
On May 3, 2013, at 00:15, reed kotler wrote: > There was some confusion on the llvm list because some tests were run on > targets that did not support the naked attribute. > > I think we are thinking now that the return statement should not be emitted > unless explicitly requested. > > It's not totally clear in the gcc manual so that is why I was asking. I clearly is an error to have a function that doesn't return. So, what you really asking is: "What are the semantics of a (naked) functon that doesn't return?" I think it would make sense for a compiler to emit a special error-return (such as abort()) at the end of such a function, with the expectation that this code usually would be unreachable and optimized away. I don't think it makes sense to try and define any other semantics for a funciotn that doesn't explicitly return a value. -Geert
