> There is no optimizer that could benefit from inlining, the only > thing saved would be a call and return, which is a silly optimization.
Unless the body of the function is single __asm__ instruction for instance. I was thinking about a simple C subset parser that produces AST of the inline if sucessful. This will leave out recursive functions or anything more "complex" in general for current impl and be able to inject back name-mangled C source from the (simple) AST. The trouble starts with local variables when the inline function is used in an expression but probably doable in few simple cases. I'm currently research peg/leg (http://piumarta.com/software/peg/) for simple C parser for inlines. cheers, </wqw> -----Original Message----- From: Tinycc-devel [mailto:[email protected]] On Behalf Of Michael Matz Sent: Thursday, April 14, 2016 3:58 PM To: [email protected] Subject: Re: [Tinycc-devel] Implementing gcc intrinsics Hi, On Wed, 13 Apr 2016, Sergey Korshunoff wrote: > > I can see that for inlines there is a separate `InlineFunc` struct > > that keeps function body until end of generation when in > > `gen_inline_functions` only the referenced inlines are generated as > > regular functions. > > Then we can search if a function to call is inline function and if so, > parse this function body in the form of the {( )} block. A compiler > switch can be used to keep old bejavior You will find that this will not work very well. Parameter passing is one problem, scoping another and recursive calls another. Parsing as ({}) block doesn't deactive the outer variables, so what should be a compile error might turn into silently accepting wrong code, or into accessing a local instead of a global variable. Functions can call themself recursively, parsing them as ({}) block that's impossible to implement. Also: for tcc inlining makes no sense whatsoever. There is no optimizer that could benefit from inlining, the only thing saved would be a call and return, which is a silly optimization. Ciao, Michael. _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
